RE: [EXTERNAL] Re: MGWG: Feedback MADO profile / DICOM modules

[O'Donnell, Kevin]

Hi Everyone,

 

Thanks Rick B for pointing out that our mailing recipient lists are getting partitioned.

Anyone here who is not currently on the ihe-rad-tech google group should go there and click Join, at the very least for the duration of this cycle. https://groups.google.com/g/ihe-rad-tech/

 

Here’s the Scenario/Framework doc I offered up on the weekend.  Elaboration welcome.

 

Cheers,

  Kevin

 

From: Andries Hamster <and...@founda.com>
Sent: Tuesday, October 14, 2025 6:48 AM
To: Rick Busbridge <rick.bu...@nictiz.nl>
Cc: Charles Parisot <cha...@interopehealth.com>; Nick Hermans <nick.h...@uzleuven.be>; Heuvel, Bas van den <bas.van.d...@philips.com>; ROBINSON, Neil (NHS ENGLAND) <neil.ro...@nhs.net>; Robin Breslin <rbre...@trumonix.co.uk>; Mark Sinke <mark....@founda.com>; desp...@externos.sanidad.gob.es; ignacio....@philips.com; jpr...@epic.com; marc.ka...@visus.com; O'Donnell, Kevin <KOdo...@MRU.MEDICAL.CANON>
Subject: [EXTERNAL] Re: MGWG: Feedback MADO profile / DICOM modules

 

Hi Rick (and others)

 

Yes, most of the extensions are ok and make sense. We can argue about optionality, but in general any DICOM attributes that helps an imaging consumer to prepare for what study it needs to render is helpful. However, there is practical limit to what we should add as there is a point where we better start discussing how to relay a QIDO-rs call through a federated network. Most of my comments focus on keeping the MADO profile as much as possible in line with the DICOM standard. 

 

The ones I have an issue with are the retrieveURI, and the proposed way to identify key images. 

 

W.r.t. the retrieveURI. This seems a solution to a specific problem that doesn't scale well in my (humble) opinion across "community boundaries" regardless whether these are clinical or geographical by nature. Furthermore, a retrieveURI is a very transient piece of information that has more a "computational" than a "persistent" characteristic. The "middle ground" here may be that we include the attribute be make it an optional attribute for both the server and the client that create/process a MADO Manifest object. 

 

W.r.t. the Key Image I fail to see (or perhaps better to say: "fail to understand") the value of adding complexity to the manifest versus the theoretical benefits it brings. Both a XDS-I (or MADO) manifest and a IHE define KIN are Key Object Selection Documents each with a different intent. When the intent of an imaging source is to only share key images it can create a MADO document with a referenced SOP instance sequence referencing the key images only. In case the intent is to share the entire DICOM study, the SOP instance sequence will also include KOS instances that identify the Key Images. It just takes one transaction from a consumer to a source to retrieve a KOS object. Charles' argument that PACS systems acting as an imaging source may have difficulties responding to a request that calls for a single instance should not be solved by creating a more complex manifest. 

 

Best regards,

 

Andries Hamster

 

 

 

 

 

On Tue, Oct 14, 2025 at 2:00 PM Rick Busbridge <rick.bu...@nictiz.nl> wrote:

Hi Andries,

 

Thanks for your review and the way in which you have presented the analysis between the original KOS IOD and the MADO version. It provides a very clear overview.

 

One general question - are you in agreement with the bulk of the proposed additional attributes in the MADO version so long as they are encoded in a non-breaking manner?

 

I'll take all of this further in the MADO sub-team and discussions with Wim Corbijn and Jeroen Medema.

 

Regards,

Rick

 

---

From: Rick Busbridge <rick.bu...@nictiz.nl>
Sent: Monday, October 13, 2025 14:39
To: Andries Hamster <and...@founda.com>; Charles Parisot <cha...@interopehealth.com>; bas.vand...@philips.com <bas.vand...@philips.com>; Nick Hermans <nick.h...@uzleuven.be>; ROBINSON, Neil (NHS ENGLAND) <neil.ro...@nhs.net>; Robin Breslin <rbre...@trumonix.co.uk>; Mark Sinke <mark....@founda.com>; desp...@externos.sanidad.gob.es <desp...@externos.sanidad.gob.es>; ignacio....@philips.com <ignacio....@philips.com>; jpr...@epic.com <jpr...@epic.com>; marc.ka...@visus.com <marc.ka...@visus.com>; ODonnell Kevin <KOdo...@mru.medical.canon>
Subject: Re: MGWG: Feedback MADO profile / DICOM modules

 

Andries,

 

I'll have a look at this tomorrow morning. I haven't got any time left today,

 

Thank you for the input - much appreciated.

 

Rick

 

---

From: Andries Hamster <and...@founda.com>
Sent: Monday, October 13, 2025 12:09
To: Charles Parisot <cha...@interopehealth.com>; Rick Busbridge <rick.bu...@nictiz.nl>; bas.vand...@philips.com <bas.vand...@philips.com>; Nick Hermans <nick.h...@uzleuven.be>; ROBINSON, Neil (NHS ENGLAND) <neil.ro...@nhs.net>; Robin Breslin <rbre...@trumonix.co.uk>; Mark Sinke <mark....@founda.com>; desp...@externos.sanidad.gob.es <desp...@externos.sanidad.gob.es>; ignacio....@philips.com <ignacio....@philips.com>; jpr...@epic.com <jpr...@epic.com>; marc.ka...@visus.com <marc.ka...@visus.com>; ODonnell Kevin <KOdo...@mru.medical.canon>
Subject: MGWG: Feedback MADO profile / DICOM modules

 

Hello all,

 

I took some time this weekend to do a thorough read of the MADO profile sections that define the DICOM Modules of the Image Manifest.

 

The attached excel sheet includes my comments. There is a bit of structure to the excel. The first sheet lists the table of the Key Object Selection IOD. Each module thereof that is defined in the MADO profile is listed in a separate sheet. They hyperlinks should help navigate. 

 

Different from the approach in the MADO profile I have kept the references to several DICOM (Attribute) Marco's in place. Relevant/referenced marcos are included in each sheet. 

 

When a cell is colored orange I have placed a comment that I believe needs to be addressed. When a cell is colored yellow I have placed a question. If a cell is colored red I believe there is a conflict with the DICOM standard. Please see column "I" in each sheet. 

 

The intend of my comments are to improve the MADO profile and balance between things the DICOM standard already defines with sufficient detail, and the additional constraints the IHE MADO profile add to some DICOM attributes. At the same time some comments may help to prevent unnecessary duplication of the DICOM standard modules/attributes making MADO more "internationally applicable" and a little less "Europe only".

 

What I haven't been able to assess is whether or not DICOM allows for extending existing Marco's with additional DICOM attributes. When asking this question to Google I get the following

 

== Google ==

Question: Can you extend a DICOM attribute macro?

 

Answer: Yes, DICOM attribute macros can be extended, either by adding to existing extended macros like the {Extended Content Identification Macro} or the {Extended Selector Attribute Macro}, or by creating new ones for specific purposes. This extension process involves adding new attributes to an existing macro definition or defining new macros entirely, often using standard mechanisms or private attributes.

 

Methods for extending DICOM attribute macros

• Adding to existing extended macros: New attributes can be added to macros that have already been defined as extensions. For example, the Extended Selector Attribute Macro includes additional attribute descriptors beyond the base Selector Attribute Macro, as described in NEMA's DICOM standards for Supplement 185.
• Creating new extended macros: Developers can define entirely new extended macros for specific applications, such as those found in the Content Assessment Results IOD.
• Using private attributes: Macros can be extended by incorporating private attributes, which are vendor-specific or user-defined attributes not part of the standard DICOM specification. This allows for the inclusion of custom data that is not covered by standard attributes.
• Defining new attribute types: New attributes can be created for new types of data. For instance, an Extended Content Identification Macro was created to support content identification that uses a label supporting lower-case characters and specified character sets, as described in NEMA's DICOM Part 3.

== 

 

Perhaps using IHE defined "private slots" is the most elegant way of achieving MADO define extension. Something like (yellow highlighted sections). If applicable/allowed such private slots can be use both for include additional series attributes, as well as image/instance attributes.

 

0040,a040 : CS : CONTAINER
0040,a043 : SQ : [sequence, item count = 1] Item #0
   0008,0100 : SH : 113030
   0008,0102 : SH : DCM
   0008,0104 : LO : Manifest
fffe,e00d : : [undefined]
0040,a050 : CS : SEPARATE
0040,a375 : SQ : [sequence, item count = 1] Item #0
   0008,1115 : SQ : [sequence, item count = 42] Item #0
     0008,0054 : AE : FC_D2X
     0008,1199 : SQ : [sequence, item count = 2] Item #0
       0008,1150 : UI : 1.2.840.10008.5.1.4.1.1.2
       0008,1155 : UI : 1.3.6.1.4.1.5962.99.1.996415582.1435156766.1615904151646.41.0
     fffe,e00d : : [undefined] Item #1
       0008,1150 : UI : 1.2.840.10008.5.1.4.1.1.2
       0008,1155 : UI : 1.3.6.1.4.1.5962.99.1.996415582.1435156766.1615904151646.46.0
     fffe,e00d : : [undefined]
     0020,000e : UI : 1.3.6.1.4.1.5962.99.1.996415582.1435156766.1615904151646.43.0
     0040,e011 : UI : 1.3.6.1.4.1.40371.2.14.31.41.1.3.10 
     0067,0010 : LO : IHE Ext Slot.
       0067,1001 : SQ : [sequence, item count = 1] Item #0
         0008,0021 : DA : 20200812
         0008,0031 : TM : 125909.894
         0008,0060 : CS : CT 0008,103e : LO : 2.0
         0018,1030 : LO : Lever 4 fase + Thorax Abdomen
         0018,5100 : CS : FFS
         0020,0011 : IS : 1
       fffe,e00d : : [undefined]
     fffe,e00d : : [undefined] Item #1
     0008,0054 : AE : FC_D2X
     0008,1199 : SQ : [sequence, item count = 2] Item #0
      0008,1150 : UI : 1.2.840.10008.5.1.4.1.1.2
      0008,1155 : UI : 1.3.6.1.4.1.5962.99.1.996415582.1435156766.1615904151646.47.0
     fffe,e00d : : [undefined] Item #1
      0008,1150 : UI : 1.2.840.10008.5.1.4.1.1.2
      0008,1155 : UI : 1.3.6.1.4.1.5962.99.1.996415582.1435156766.1615904151646.50.0
     fffe,e00d : : [undefined]
     0020,000e : UI : 1.3.6.1.4.1.5962.99.1.996415582.1435156766.1615904151646.48.0
     0040,e011 : UI : 1.3.6.1.4.1.40371.2.14.31.41.1.3.10 
     0067,0010 : LO : IHE Ext Slot.
       0067,1001 : SQ : [sequence, item count = 1] Item #0
         0008,0021 : DA : 20200812
         0008,0031 : TM : 125909.894
         0008,0060 : CS : CT
         0008,103e : LO : 2.0
         0018,1030 : LO : Lever 4 fase + Thorax Abdomen
         0018,5100 : CS : FFS
         0020,0011 : IS : 2
     fffe,e00d : : [undefined]
   fffe,e00d : : [undefined] Item #2
...

 

I am unfortunately not available this and next week for the call on Thursday due to a small PTO break. Back in the first week of november. Perhaps the comments in the excel can be assessed by the group, and decided whether or not they make sense.

 

Best regards,

 

Andries Hamster

EVP Business Development

Phone:    +31 6 55 82 32 89

Email:      and...@founda.com

Website:  foundahealth.com

[O'Donnell, Kevin]

Hi Folks,

 

I also wanted to express agreement with a few of the things Andries said earlier.

• “there is practical limit to what we should add as there is a point where we better start discussing how to relay a QIDO-rs call through a federated network.”
• Fully agree that achieving that unlocks a lot of capabilities that are symmetric with local functions so for things that work for Local Viewing, you don’t have to re-invent them to work across a federated network.
• “a retrieveURI is a very transient piece of information that has more a "computational" than a "persistent" characteristic.”
• That is one of the reasons we’ve been discussing an Instance Registry Service in DICOM WG-10. A source client could register (and remove) instance availability. A client could then provide the UID for an Instance (or a study or series) and get back a list of endpoints where it is currently available.  When a hospital re-architects it’s DMZ, or shifts long term data to a regional archive, it would be a lot easier to update some registry records than to go chase down and rewrite a bazillion hyperlinks embedded in reports, KOS, manifests, and the like.  Which I think is the nature of the problem you were imagining.
• “When the intent of an imaging source is to only share key images it can create a MADO document with a referenced SOP instance sequence referencing the key images only. In case the intent is to share the entire DICOM study, the SOP instance sequence will also include KOS instances that identify the Key Images.”
• Agreed. I tried to reflect this pattern in the Full Manifest vs Slim Manifest slide.

[cha...@interopehealth.com]

Hi Folks,

 

Thanks to Andries and Kevin for their analysis.

 

I also agree that we should limit ourselves in extending the Imaging Study Manifest.  That has always been the intend.

This limit is also driven by the concerns about privacy minimize exposing clinical information, while still offering useful information for the clinician to decide on the basis of the Manifest if an imaging study is worth retrieving (actually clinician are asking to have enough information to decide not to retrieve images).  That is why the current MADO proposal only adds the minimum:

• Institution Code Sequence
• Invoke Image Display URL
• Series Date and Time
• Modality
• Series Description
• Instance Number
• Number of Frames
• Significant Image

This reflects a compilation of the critically needed extensions that have been actually implemented in countries with review by clinicians and collected by the Multi-Country WG and confirmed by the Xt-HER and HL7-IHE Europe folks.

 

The Invoke Image Display URL (Retrieve URI) will be discussed this afternoon.

 

On the point of publishing only “key images”, lets not mix the fact that the source of images that creates the manifest is ultimately in charge of excluding some subset of its local imaging study.  Let not forget that some policies/regulatory requirements (requiring not to exclude or to exclude) may also be applicable.  So, we need to stay out of placing rules and design constraints that are only going to create complexities when the WADO-RS retrieved are processed, especially when they are at the study level as the publication exclusion applied with the manifest may have to be applied at that time.

 

I was mis-understood about the fact that PACS systems acting as an imaging source may have difficulties responding to a request that calls for a single instance should not be solved by creating a more complex manifest.  These are two separate points (performance of image retrieve on one side and optimize management of manifests on the other) that have no relationship. 

On the point of the optimization of the management of manifests, the current MADO Manifest proposal is not to create a complex Manifest, but to create a useful manifest.  Useful in offering a consistent view to clinicians on the imaging study they expect to be presented in a timely and consistent fashion once an imaging study has been filtered in response to the manifest query. 

The approach based on a slim manifest(s) combined with a full manifest adds some clear complexities versus the approach of single manifest with minimal extensions.  I have presented this alternative approach to a few implementers, they do not welcome any multi-manifest approach.  The added complexity is not obvious and requires a rather extensive explanation that I will cover in a separate e-mail.

 

Regards

Charles

 

De : ihe-ra...@googlegroups.com <ihe-ra...@googlegroups.com> De la part de O'Donnell, Kevin
Envoyé : jeudi 16 octobre 2025 04:20
À : Andries Hamster <and...@founda.com>; Rick Busbridge <rick.bu...@nictiz.nl>
Cc : Charles Parisot <cha...@interopehealth.com>; Nick Hermans <nick.h...@uzleuven.be>; Heuvel, Bas van den <bas.van.d...@philips.com>; ROBINSON, Neil (NHS ENGLAND) <neil.ro...@nhs.net>; Robin Breslin <rbre...@trumonix.co.uk>; Mark Sinke <mark....@founda.com>; desp...@externos.sanidad.gob.es; ignacio....@philips.com; jpr...@epic.com; marc.ka...@visus.com; ihe-ra...@googlegroups.com
Objet : [IHE-Rad-Tech4306] RE: [EXTERNAL] Re: MGWG: Feedback MADO profile / DICOM modules

--
You received this message because you are subscribed to the Google Groups "IHE Radiology Technical Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to IHE-Rad-Tech...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/IHE-Rad-Tech/LV8PR18MB56791EB0FC3ED259A3D366B7FCE9A%40LV8PR18MB5679.namprd18.prod.outlook.com.

[O'Donnell, Kevin]

Hi Folks,

 

Attached and in the Google drive are updates to the MADO Scenarios discussion file to reflect points at the meeting this week.

 

Cheers,

  Kevin

[Corbijn van Willenswaard, Wim]

Hi,

 

I have uploaded the overview presentation discussed last Thursday.

Slightly adopted to cover some (might not be complete) of the remarks given during the discussion.

 

Regards,

Wim

 

 

 

 

(Friday is my day off)

 

From: ihe-ra...@googlegroups.com <ihe-ra...@googlegroups.com> On Behalf Of O'Donnell, Kevin
Sent: Saturday, October 18, 2025 1:07 AM
To: cha...@interopehealth.com; Andries Hamster <and...@founda.com>; Rick Busbridge <rick.bu...@nictiz.nl>
Cc: 'Nick Hermans' <nick.h...@uzleuven.be>; Heuvel, Bas van den <bas.van.d...@philips.com>; 'ROBINSON, Neil (NHS ENGLAND)' <neil.ro...@nhs.net>; 'Robin Breslin' <rbre...@trumonix.co.uk>; 'Mark Sinke' <mark....@founda.com>; desp...@externos.sanidad.gob.es; Jauregui, Ignacio <ignacio....@philips.com>; jpr...@epic.com; Kämmerer, Marc <marc.ka...@visus.com>; ihe-ra...@googlegroups.com
Subject: [IHE-Rad-Tech4327] Updated MADO Scenarios File

 

Caution: This e-mail originated from outside of Philips, be careful for phishing.

 

--

You received this message because you are subscribed to the Google Groups "IHE Radiology Technical Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to IHE-Rad-Tech...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/IHE-Rad-Tech/LV8PR18MB5679FE09CA0A01DBDCEBF0CFFCF6A%40LV8PR18MB5679.namprd18.prod.outlook.com.

---

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

[cha...@interopehealth.com]

Hi,

 

Thanks, Kevin for the updated slides. 

Attached and on the Google Drive an expanded and annotated version.

 

Regards

Charles Parisot

 

 

De : O'Donnell, Kevin <KOdo...@MRU.MEDICAL.CANON>
Envoyé : samedi 18 octobre 2025 01:07
À : cha...@interopehealth.com; 'Andries Hamster' <and...@founda.com>; 'Rick Busbridge' <rick.bu...@nictiz.nl>
Cc : 'Nick Hermans' <nick.h...@uzleuven.be>; 'Heuvel, Bas van den' <bas.van.d...@philips.com>; 'ROBINSON, Neil (NHS ENGLAND)' <neil.ro...@nhs.net>; 'Robin Breslin' <rbre...@trumonix.co.uk>; 'Mark Sinke' <mark....@founda.com>; desp...@externos.sanidad.gob.es; ignacio....@philips.com; jpr...@epic.com; marc.ka...@visus.com; ihe-ra...@googlegroups.com
Objet : Updated MADO Scenarios File

[David Clunie]

Hi

Very short version: DNNFEM, use QIDO

Short version: consider just leveraging DICOMweb query or metadata retrieval for
filtration criteria rather than an extended manifest, if you are using DICOMweb
at all

TL;DNR:

Reviewing the latest summary, one thing I still do not understand is why, if (one of)
the goal(s) is to make remote viewing as seamless as local viewing, there is not more
emphasis on just using the DICOMweb (WADO/QIDO-RS) services, even if used across some
cross-community cross-national gateway/proxy.

If the images themselves are ultimately going to be retrieved as DICOM PS3.10 files
using DICOMweb, or interactively accessed as metadata/bulkdata/pixeldata using DICOMweb,
then I am not sure why you would eschew using DICOMweb QIDO-RS or DICOMweb WADO-RS
metadata resources for the viewer (or study/series browser that spawns the viewer) to
get that metadata.

I.e., in a modern setting, the remote selection/viewing experience and implementation
need be no different in function or mechanism from that for local viewing (just as with
the Zero Trust security paradigm, local users are treated the same as remote users).

I get that a document-based manifest has been demonstrated to have utility for leveraging
a document-based sharing mechanism to identify those studies that are being shared, and I
am not arguing against that,

But once those studies have been identified, since viewing them seems (in your proposal)
to require access via DICOMweb mechanisms, why complicate the proceedings by requiring a
different mechanism than DICOMweb query and metadata retrieval for the viewer?

I.e., a current DICOMweb browser/viewer can be used with any endpoint, remote or
local, once access is granted, without the need for it to be extended with knowledge
of manifests regardless of their encoding (DICOM KOS, DICOM something else
persistent, FHIR ImagingStudy, whether the last is live or bundled as a document).

In short, either you can access the images and metadata and query, or you can't, so
why do you need a manifest (or an extended manifest with more metadata) as well to
augment what is already available (beyond selection by identity of entities)?

Or to express this in another way, if you can ever view it, even if you decide not to
based on the metadata, the filter for the decision to view or not can still be based
on actively queried or retrieved metadata from DICOMweb, rather than having it
communicated by some novel, additional, mechanism inside a new variant of manifest.

Such DICOMweb queries and retrievals can be made by any application - it doesn't have
to be used only within the viewer or study browser.

This seems to be true regardless of whether the selection of images to be shared is
a subset of key images that have previously been deemed to be of interest, or an
entire study or set of studies for a patient.

As well as true irrespective of whether IID is used to spawn the viewer or not (since
all that needs are the identifiers of the entities to be viewed and the endpoint).

A corollary of this is that, even though FHIR ImagingStudy may contain more than
just the identifiers of the DICOM entities (study/series/instance), in terms of
descriptive metadata, you don't need it, since you can get it from the DICOMweb
query or metadata retrieval, which you have to be able to do as a browser/viewer
anyway, when FHIR isn't involved. So just because it is in FHIR ImagingStudy,
doesn't mean there is utility in replicating it in a DICOM KOS or similar object,
if it isn't needed in the first place, since that is just yet another way to do
(a subset of) the same thing as DICOMweb, leading to yet more interoperability
challenges in the field (unless you just never want to do DICOMweb in the viewer).

To paraphrase the "key use case" from the original MADO proposal document:

1. A system acting as an imaging document consumer has access to imaging study
manifests (the way manifests are accessed and exchanged is out of scope of the
use case).

2. A user on this system uses the content of any such imaging study manifest to
query for metadata (using the location information provided in the imaging study
manifest) and uses that to choose an entire imaging study or a subset (series,
set of instances, key images).

3. The imaging document consumer requests the retrieval of (or interactive access
to) these selected DICOM objects to the remote imaging sources (using the location
information provided in the imaging study manifest).

4. This request retrieval (or interactive access) is received by an imaging source
and the corresponding DICOM instances are accessed from its internal storage and
returned to the requesting imaging document consumer.

5. The imaging document consumer receives (interactively accesses) the DICOM Instances,
in the format requested, and processes them.

Not sure that I am convinced there is a need for "using the location information
provided in the imaging study manifest", since that has security and scalability
and long term stability implications, but that is a separate discussion.

If you do need to communicate it and it is not pre-configured, then what is needed
for the DICOMweb approach is the base endpoint to which the DICOMweb resources are
appended, and not the retrieve URLs of individual instances.

Note that I have also emphasized "interactive access", since in some use cases
(esp., digital pathology) it is desirable to separate the metadata and the pixel data
frames when viewing does not require retrieving the entire object.

David

PS. I get that it may be slightly more work to get some series-level metadata using
DICOMweb, like Series Description, but that is why there are composite attributes
like Modalities in Study specified as required in the DICOMweb query at Study level:

https://dicom.nema.org/medical/dicom/current/output/html/part18.html#table_10.6.3-3

It really isn't that hard, e.g.:

curl --insecure 'https://ihe.j4care.com:18443/dcm4chee-arc/aets/DCM4CHEE/rs/studies?StudyInstanceUID=2.25.189158677934950560126618528446322890163' | jq

curl --insecure 'https://ihe.j4care.com:18443/dcm4chee-arc/aets/DCM4CHEE/rs/studies/2.25.189158677934950560126618528446322890163/series?' | jq

(though in this example Series Description is actually empty, but you see where it
is returned).

And if you just want all the metadata to filter client-side:

curl --insecure 'https://ihe.j4care.com:18443/dcm4chee-arc/aets/DCM4CHEE/rs/studies/2.25.189158677934950560126618528446322890163/metadata' | jq

How hard is that?

On 10/21/25 6:14 PM, charles via IHE Radiology Technical Committee wrote:
> Hi,
>
> Thanks, Kevin for the updated slides.
>
> Attached and on the Google Drive an expanded and annotated version.
>
> Regards
>
> Charles Parisot
>

> *De :*O'Donnell, Kevin <KOdo...@MRU.MEDICAL.CANON>
> *Envoyé :* samedi 18 octobre 2025 01:07
> *À :* cha...@interopehealth.com; 'Andries Hamster' <and...@founda.com>; 'Rick Busbridge' <rick.bu...@nictiz.nl>
> *Cc :* 'Nick Hermans' <nick.h...@uzleuven.be>; 'Heuvel, Bas van den' <bas.van.d...@philips.com>; 'ROBINSON, Neil (NHS ENGLAND)' <neil.ro...@nhs.net>; 'Robin Breslin' <rbre...@trumonix.co.uk>; 'Mark Sinke' <mark....@founda.com>; desp...@externos.sanidad.gob.es; ignacio....@philips.com; jpr...@epic.com; marc.ka...@visus.com; ihe-ra...@googlegroups.com
> *Objet :* Updated MADO Scenarios File

>
> Hi Folks,
>
> Attached and in the Google drive are updates to the MADO Scenarios discussion file to reflect points at the meeting this week.
>
> Cheers,
>
>   Kevin
>

> --
> You received this message because you are subscribed to the Google Groups "IHE Radiology Technical Committee" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to IHE-Rad-Tech...@googlegroups.com <mailto:IHE-Rad-Tech...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/IHE-Rad-Tech/a47f01dc42d8%2423708ca0%246a51a5e0%24%40interopehealth.com <https://groups.google.com/d/msgid/IHE-Rad-Tech/a47f01dc42d8%2423708ca0%246a51a5e0%24%40interopehealth.com?utm_medium=email&utm_source=footer>.

[David Clunie]

Right, but the question is who needs what metadata and when?

If you can view the images (via DICOMweb), you can get the metadata (via DICOMweb).

If you can't view the images, you don't need the metadata.

I don't see DICOM meta-data as being any more or less complex than FHIR ImagingStudy
metadata or KOS encoded metadata (whether in the content tree or buried in extended
SOP Class attributes inserted into hierarchical instance reference macros).

I just wanted to walk through the use-cases and the services involved/available to
see if there was an alternative to an extended manifest.

In that way perhaps we could preclude the need to addressing the separable issue of
the abomination that is the current proposal to flagrantly violate the Current
Requested Procedure Evidence Sequence.

If not, I guess nuclear war is inevitable.

David

On 10/23/25 7:45 AM, Robin Breslin wrote:
> Dave,
>
> I decided to read the TL;DNR (after having used ChatGPT to help me decipher the helpful acronyms).
>
> There is a lot in your message, I know some of which has been discussed before. I think the answer is not simple and I need more time to digest and discuss with my colleagues - but I wanted to reply and thank you for your (as usual) thoughtful input.
>
> Here I am just expressing my views. I too have concerns about the KOS (and Manifests) as transport mechanisms for meta-data. But in short, if you have an architecture that has a Registry separate from the PACS (or let's say PACSs, because there would be many PACSs in a region) then that Registry probably would not maintain all the necessary meta-data to reliably respond to a QIDO - you need some other mechanism to get the (essentially DICOM) meta-data out to the consumer.  This is the KOS or Manifest paradigm used by IHE for this - and extending this paradigm seems pragmatic.
>
> This is not straight forward (at least not for me) and I see all of this work as an evolution eventually (probably) landing on the RESTful paradigm. Even so, the complexity of DICOM meta-data will always pose a challenge I think.
>
> [Not available 27-30 Oct]
>
> *Robin Breslin*
>
> Trumonix Ltd
> Mobile +44(0)7852 886314

>> > *Envoyé :* samedi 18 octobre 2025 01:07

>> > *À :* cha...@interopehealth.com; 'Andries Hamster' ; 'Rick Busbridge'
>> > *Cc :* 'Nick Hermans' ; 'Heuvel, Bas van den' ; 'ROBINSON, Neil (NHS ENGLAND)' ; 'Robin Breslin' ; 'Mark Sinke' ; desp...@externos.sanidad.gob.es; ignacio....@philips.com; jpr...@epic.com; marc.ka...@visus.com; ihe-ra...@googlegroups.com

>> > *Objet :* Updated MADO Scenarios File
>> >
>> > Hi Folks,
>> >
>> > Attached and in the Google drive are updates to the MADO Scenarios discussion file to reflect points at the meeting this week.
>> >
>> > Cheers,
>> >
>> >   Kevin
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups "IHE Radiology Technical Committee" group.

>> > To unsubscribe from this group and stop receiving emails from it, send an email to IHE-Rad-Tech...@googlegroups.com .
>> > To view this discussion visit https://groups.google.com/d/msgid/IHE-Rad-Tech/a47f01dc42d8%2423708ca0%246a51a5e0%24%40interopehealth.com .
>>

[O'Donnell, Kevin]

Hi Folks,

I took Wims suggestion to do up some interaction diagrams which are now in the first 7 slides of the PPT.
It's not complete with all scenarios, but starts with the simplified model of what the user is trying to achieve.
The "baseline" local viewing paradigm is on Slide 3. Slide 4 is what I think David is describing. Slide 5 is what that might evolve into in the FHIR Future. Slide 6 is the expanded KOS.

Slide 7 highlights that the Identify Images/Series of Interest step is the crux of most variations. It starts to get into some of the different needs/patterns of identifying a subset.

Feel free to add/augment slides as useful. The slide notes have the corresponding code for editing.

Cheers,
Kevin

>> https://urldefense.com/v3/__https://dicom.nema.org/medical/dicom/curr
>> ent/output/html/part18.html*table_10.6.3-3__;Iw!!Ai2CFrZnFhI!6UatFBft
>> qmcy_0CTFQq0dpFCoMJ-QrUeljLesgTiBa4S2QqDWcy5UgwxBBXE4XUF_dL4vokfmbi18
>> 8nguujiyxD3$

>>
>> It really isn't that hard, e.g.:
>>
>> curl --insecure

>> 'https://urldefense.com/v3/__https://ihe.j4care.com:18443/dcm4chee-ar
>> c/aets/DCM4CHEE/rs/studies?StudyInstanceUID=2.25.18915867793495056012
>> 6618528446322890163__;!!Ai2CFrZnFhI!6UatFBftqmcy_0CTFQq0dpFCoMJ-QrUel
>> jLesgTiBa4S2QqDWcy5UgwxBBXE4XUF_dL4vokfmbi188ngukrZT5NH$ ' | jq
>>
>> curl --insecure
>> 'https://urldefense.com/v3/__https://ihe.j4care.com:18443/dcm4chee-ar
>> c/aets/DCM4CHEE/rs/studies/2.25.1891586779349505601266185284463228901
>> 63/series?__;!!Ai2CFrZnFhI!6UatFBftqmcy_0CTFQq0dpFCoMJ-QrUeljLesgTiBa
>> 4S2QqDWcy5UgwxBBXE4XUF_dL4vokfmbi188nguhTAd4wR$ ' | jq

>>
>> (though in this example Series Description is actually empty, but you
>> see where it is returned).
>>
>> And if you just want all the metadata to filter client-side:
>>
>> curl --insecure

>> 'https://urldefense.com/v3/__https://ihe.j4care.com:18443/dcm4chee-ar
>> c/aets/DCM4CHEE/rs/studies/2.25.1891586779349505601266185284463228901
>> 63/metadata__;!!Ai2CFrZnFhI!6UatFBftqmcy_0CTFQq0dpFCoMJ-QrUeljLesgTiB
>> a4S2QqDWcy5UgwxBBXE4XUF_dL4vokfmbi188nguql_3EUv$ ' | jq

>>
>> How hard is that?
>>
>> On 10/21/25 6:14 PM, charles via IHE Radiology Technical Committee wrote:
>> > Hi,
>> >
>> > Thanks, Kevin for the updated slides.
>> >
>> > Attached and on the Google Drive an expanded and annotated version.
>> >
>> > Regards
>> >
>> > Charles Parisot
>> >
>> > *De :*O'Donnell, Kevin
>> > *Envoyé :* samedi 18 octobre 2025 01:07 *À :*
>> > cha...@interopehealth.com; 'Andries Hamster' ; 'Rick Busbridge'
>> > *Cc :* 'Nick Hermans' ; 'Heuvel, Bas van den' ; 'ROBINSON, Neil
>> > (NHS ENGLAND)' ; 'Robin Breslin' ; 'Mark Sinke' ;
>> > desp...@externos.sanidad.gob.es; ignacio....@philips.com;
>> > jpr...@epic.com; marc.ka...@visus.com;
>> > ihe-ra...@googlegroups.com *Objet :* Updated MADO Scenarios File
>> >
>> > Hi Folks,
>> >
>> > Attached and in the Google drive are updates to the MADO Scenarios discussion file to reflect points at the meeting this week.
>> >
>> > Cheers,
>> >
>> >   Kevin
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups "IHE Radiology Technical Committee" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an email to IHE-Rad-Tech...@googlegroups.com .

>> > To view this discussion visit https://urldefense.com/v3/__https://groups.google.com/d/msgid/IHE-Rad-Tech/a47f01dc42d8*2423708ca0*246a51a5e0*24*40interopehealth.com__;JSUlJQ!!Ai2CFrZnFhI!6UatFBftqmcy_0CTFQq0dpFCoMJ-QrUeljLesgTiBa4S2QqDWcy5UgwxBBXE4XUF_dL4vokfmbi188ngukTfL3Xo$ .
>>

[Ho, Kinson]

Thanks Kevin for the presentation. This is very helpful.

For the cases that the Imaging Document Source is publishing multiple manifests (full/slim), additional KIN or additional metadata in manifest, we are making the following assumptions:

• For the consumer to retrieve just the key images, the manifest / KIN / metadata ONLY tells the consumer what it may be interested. The consumer has to issue object-by-object retrieval to retrieve what is specified because there is no easy mechanism today to day ‘retrieve all objects referenced in this KIN or manifest’.
• As far as my experience, most consumers retrieve the manifest and simply use the study instance UID to issue a study level retrieve, not object-by-object
• This is especially true if we are considering a remote retrieval scenario in MADO.
• For the source to add multiple manifests / KIN / metadata, the source knows what are relevant for all clients in all scenarios such that the clients can retrieve just the key images.
• Not sure this is a reasonable assumption
• If not, then we are potentially running into a potential loop that a client needs additional metadata not already published by the source; the source then adds new metadata and publishes additional manifest / KIN / metadata
• What about existing manifests already published? Do we need to update them using the existing XDS mechanism?

So it seems like by trying to have the source provide more information to the client, we are making both the source and consumer more complicated (also as stated in the presentation).

Fundamentally, there is no straightforward retrieve mechanism to retrieve just the key images. I think something new needs to be introduced for this to support MADO efficiently.

Furthermore, if the source can actually make this decision in the first place, then why not have the consumer simply ask the source to return key images of the study (e.g. new WADO-RS retrieve at the study level with /key-images parameter, or new DIMSE equivalent), with additional options to support different ‘key images’ in different scenarios (by study type, by client, etc.). Then no change to existing XDS-I. Simple enhancement in consumers to request key images, if needed, when retrieving the study from Imaging Document Source. Most of the work will be done by the source, which is the case anyway.

Just a thought.

Thanks,

Kinson

From: ihe-ra...@googlegroups.com <ihe-ra...@googlegroups.com> on behalf of O'Donnell, Kevin <KOdo...@MRU.MEDICAL.CANON>
Date: Friday, October 24, 2025 at 10:07 PM
To: David Clunie <dcl...@dclunie.com>, Robin Breslin <rbre...@trumonix.co.uk>
Cc: Nick Hermans <nick.h...@uzleuven.be>, bas.van.d...@philips.com <bas.van.d...@philips.com>, ROBINSON, Neil (NHS ENGLAND & NHS IMPROVEMENT - X24) <neil.ro...@nhs.net>, mark....@founda.com <mark....@founda.com>, desp...@externos.sanidad.gob.es <desp...@externos.sanidad.gob.es>, ignacio....@philips.com <ignacio....@philips.com>, Josh Priebe <jpr...@epic.com>, marc.ka...@visus.com <marc.ka...@visus.com>, Rick Busbridge <rick.bu...@nictiz.nl>, Andries Hamster <and...@founda.com>, cha...@interopehealth.com <cha...@interopehealth.com>, ihe-ra...@googlegroups.com <ihe-ra...@googlegroups.com>
Subject: [IHE-Rad-Tech] RE: Why not DICOMweb query or metadata retrieval rather than extended manifest, was Re: [IHE-Rad-Tech4348] RE: Updated MADO Scenarios File

Caution: External email. Do not open attachments or click on links if you do not recognize the sender.

To view this discussion visit https://urldefense.com/v3/__https://groups.google.com/d/msgid/IHE-Rad-Tech/LV8PR18MB5679C725A78208F7BABF099DFCFEA*40LV8PR18MB5679.namprd18.prod.outlook.com__;JQ!!IqUcNYopQPk7!PiwUI7JBgZzqeWZi_EGddhjnqr1mxCaQ6p4MFXdTOUKFB3dSgHloBqKrJ6FWNWZblUK7tvURxQLxR-SnSsng1LJYaAk$ .

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or intended recipient’s authorized agent, the reader is hereby
notified that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

[David Clunie]

Not sure I understand your extra slide, Rick.

But to the question "How do you get the QIDO endpoint from the KOS Manifest?"

The answer (if not pre-configuration) is probably at the Series level [1]:

Key Object Document Module > Current Requested Procedure Evidence Sequence > Referenced Series Sequence > Retrieve URL

Arguably, one could consider adding Retrieve URL at the next level up (Study level) as well,
as it was used in the Inventory IOD for this purpose [2], which would not be inconsistent
with the intent of Current Requested Procedure Evidence Sequence (unlike the descriptive
attributes proposed), and given an appropriate position in the hierarchical macro, would
not need to be nested in a Study Access End Points Sequence.

That would mirror the provision of an end point in the FHIR ImagingStudy, which can currently
be done at the study and series level, AFAIK.

All issues of stability/staleness/permissions issues of explicit endpoints aside, of course.

These apply equally to FHIR ImagingStudy document bundles too I would think - i.e., either
the manifest (DICOM KOS or FHIR ImagingStudy) provider has current location information,
accessible by the consumer, or it doesn't, regardless of the document-as-a-message format
selected (unless you are doing live FHIR to the endpoint that actually has the images, or
a (federated?) proxy thereof).

Note that for the study vs. series endpoint question, we do currently host different series
for the same study at different endpoints (e.g., we have image servers and derived annotation
servers such as for AI results) that we visualize together in the same viewer, but I am not
sure how often that is done for large scale loosely coupled clinical sharing scenarios.

I.e., there may be value in using a series-specific endpoint, and it may not be needed in
the 90% sharing use case, and a simplification may be sufficient (either add the attribute
at the study reference level, or add a rule in your profile that the series level reference
endpoints be the same for all series in the same study).

David

1. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.17.2.html

2. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.38.html#para_efe9e18e-f564-4d98-87a5-698fee6b9857

On 10/28/25 5:03 AM, Rick Busbridge wrote:
> Hi all,
>
> I don't have access rights to update the slide-deck on the google drive. I took the latest version "*IHE MADO Scenarios-2025.10.27-CP-KOD*"**and added a question in slide 4, comment in slide 5 and a new slide 7 which shows the transactions needed if you first get the KOS and then use WADO to retrieve the KIN(s) to allow the relevant (significant image) retrieval by WADO too - this allows a comparison with slide 6.
>
> Can someone either give me update access to the google drive or save the attached slide-deck "*IHE MADO Scenarios-2025.10.28-CP-KOD-RB*" there for me?
>
> Thanks,
>
> Rick
>
> Met vriendelijke groet,
>
> ​​*Rick Busbridge*, Specialist gegevensuitwisseling
> /Afdeling: Product O&B - Generieke Standaarden/
>
> _<http://nictiz.nl/>_
>
> Oude Middenweg 55 | 2491 AC Den Haag | _www.nictiz.nl <https://nictiz.nl/>_ | KvK 27246881
> _rick.bu...@nictiz.nl <mailto:rick.bu...@nictiz.nl>_ | _LinkedIn <https://www.linkedin.com/company/nictiz>_
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Ho, Kinson <kins...@optum.com>
> *Sent:* Monday, October 27, 2025 18:18
> *To:* O'Donnell, Kevin <KOdo...@MRU.MEDICAL.CANON>; David Clunie <dcl...@dclunie.com>; Robin Breslin <rbre...@trumonix.co.uk>
> *Cc:* Nick Hermans <nick.h...@uzleuven.be>; bas.van.d...@philips.com <bas.van.d...@philips.com>; ROBINSON, Neil (NHS ENGLAND & NHS IMPROVEMENT - X24) <neil.ro...@nhs.net>; mark....@founda.com <mark....@founda.com>; desp...@externos.sanidad.gob.es <desp...@externos.sanidad.gob.es>; ignacio....@philips.com <ignacio....@philips.com>; Josh Priebe <jpr...@epic.com>; marc.ka...@visus.com <marc.ka...@visus.com>; Rick Busbridge <rick.bu...@nictiz.nl>; Andries Hamster <and...@founda.com>; cha...@interopehealth.com <cha...@interopehealth.com>; ihe-ra...@googlegroups.com <ihe-ra...@googlegroups.com>
> *Subject:* Re: Why not DICOMweb query or metadata retrieval rather than extended manifest, was Re: [IHE-Rad-Tech4348] RE: Updated MADO Scenarios File
>
> You don't often get email from kins...@optum.com. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>

>
>
> Thanks Kevin for the presentation. This is very helpful.
>
> For the cases that the Imaging Document Source is publishing multiple manifests (full/slim), additional KIN or additional metadata in manifest, we are making the following assumptions:
>

> *

> For the consumer to retrieve just the key images, the manifest / KIN / metadata ONLY tells the consumer what it may be interested. The consumer has to issue object-by-object retrieval to retrieve what is specified because there is no easy mechanism today to day ‘retrieve all objects referenced in this KIN or manifest’.

> o

> As far as my experience, most consumers retrieve the manifest and simply use the study instance UID to issue a study level retrieve, not object-by-object

> o

> This is especially true if we are considering a remote retrieval scenario in MADO.

> *

> For the source to add multiple manifests / KIN / metadata, the source knows what are relevant for all clients in all scenarios such that the clients can retrieve just the key images.

> o

> Not sure this is a reasonable assumption

> o

> If not, then we are potentially running into a potential loop that a client needs additional metadata not already published by the source; the source then adds new metadata and publishes additional manifest / KIN / metadata

> +

> What about existing manifests already published? Do we need to update them using the existing XDS mechanism?
>
>
> So it seems like by trying to have the source provide more information to the client, we are making both the source and consumer more complicated (also as stated in the presentation).
>
> Fundamentally, there is no straightforward retrieve mechanism to retrieve just the key images. I think something new needs to be introduced for this to support MADO efficiently.
>
> Furthermore, if the source can actually make this decision in the first place, then why not have the consumer simply ask the source to return key images of the study (e.g. new WADO-RS retrieve at the study level with /key-images parameter, or new DIMSE equivalent), with additional options to support different ‘key images’ in different scenarios (by study type, by client, etc.). Then no change to existing XDS-I. Simple enhancement in consumers to request key images, if needed, when retrieving the study from Imaging Document Source. Most of the work will be done by the source, which is the case anyway.
>
> Just a thought.
>
> Thanks,
>
> Kinson
>

> *From: *ihe-ra...@googlegroups.com <ihe-ra...@googlegroups.com> on behalf of O'Donnell, Kevin <KOdo...@MRU.MEDICAL.CANON>
> *Date: *Friday, October 24, 2025 at 10:07 PM
> *To: *David Clunie <dcl...@dclunie.com>, Robin Breslin <rbre...@trumonix.co.uk>
> *Cc: *Nick Hermans <nick.h...@uzleuven.be>, bas.van.d...@philips.com <bas.van.d...@philips.com>, ROBINSON, Neil (NHS ENGLAND & NHS IMPROVEMENT - X24) <neil.ro...@nhs.net>, mark....@founda.com <mark....@founda.com>, desp...@externos.sanidad.gob.es <desp...@externos.sanidad.gob.es>, ignacio....@philips.com <ignacio....@philips.com>, Josh Priebe <jpr...@epic.com>, marc.ka...@visus.com <marc.ka...@visus.com>, Rick Busbridge <rick.bu...@nictiz.nl>, Andries Hamster <and...@founda.com>, cha...@interopehealth.com <cha...@interopehealth.com>, ihe-ra...@googlegroups.com <ihe-ra...@googlegroups.com>
> *Subject: *[IHE-Rad-Tech] RE: Why not DICOMweb query or metadata retrieval rather than extended manifest, was Re: [IHE-Rad-Tech4348] RE: Updated MADO Scenarios File

> >> https://urldefense.com/v3/__https://dicom.nema.org/medical/dicom/curr <https://urldefense.com/v3/__https://dicom.nema.org/medical/dicom/curr>

> >> > To view this discussion visit https://urldefense.com/v3/__https://groups.google.com/d/msgid/IHE-Rad-Tech/a47f01dc42d8*2423708ca0*246a51a5e0*24*40interopehealth.com__;JSUlJQ!!Ai2CFrZnFhI!6UatFBftqmcy_0CTFQq0dpFCoMJ-QrUeljLesgTiBa4S2QqDWcy5UgwxBBXE4XUF_dL4vokfmbi188ngukTfL3Xo$ <https://urldefense.com/v3/__https://groups.google.com/d/msgid/IHE-Rad-Tech/a47f01dc42d8*2423708ca0*246a51a5e0*24*40interopehealth.com__;JSUlJQ!!Ai2CFrZnFhI!6UatFBftqmcy_0CTFQq0dpFCoMJ-QrUeljLesgTiBa4S2QqDWcy5UgwxBBXE4XUF_dL4vokfmbi188ngukTfL3Xo$>  .

> >>
>
> --
> You received this message because you are subscribed to the Google Groups "IHE Radiology Technical Committee" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to IHE-Rad-Tech...@googlegroups.com.

> To view this discussion visit https://urldefense.com/v3/__https://groups.google.com/d/msgid/IHE-Rad-Tech/LV8PR18MB5679C725A78208F7BABF099DFCFEA*40LV8PR18MB5679.namprd18.prod.outlook.com__;JQ!!IqUcNYopQPk7!PiwUI7JBgZzqeWZi_EGddhjnqr1mxCaQ6p4MFXdTOUKFB3dSgHloBqKrJ6FWNWZblUK7tvURxQLxR-SnSsng1LJYaAk$ <https://urldefense.com/v3/__https://groups.google.com/d/msgid/IHE-Rad-Tech/LV8PR18MB5679C725A78208F7BABF099DFCFEA*40LV8PR18MB5679.namprd18.prod.outlook.com__;JQ!!IqUcNYopQPk7!PiwUI7JBgZzqeWZi_EGddhjnqr1mxCaQ6p4MFXdTOUKFB3dSgHloBqKrJ6FWNWZblUK7tvURxQLxR-SnSsng1LJYaAk$> .

[David Clunie]

Hi Rick

I took a quick look at your new slides and on Slide 14 on the XC scenario you say:

"Can QIDO be used in the XC setting for obtaining additional imaging study metadata to allow User Physician selection of relevant imaging study instances for retrieval?

Answer: No – QIDO cannot be used in a XC setting as there is no Local Client access to the Source PACS."

but then go on in the next slide to use WADO for XC viewing that does.

Why are you treating QIDO and WADO differently wrt. XC capabilities?

If the source PACS is implementing DICOMweb at all, it will typically provide both
QIDO and QADO Study services, and there is no reason I know of that the local and
source gateways can't do any necessary identifier and URL re-writing for either.

I.e., this is back to my original point that if you can do WADO you can do QIDO, so
you don't need an extended manifest if you have QIDO.

Otherwise this doesn't seem to be a valid comparison of the capabilities.

See my attached rough update of your diagram for QIDO.

David

On 10/31/25 5:30 AM, Rick Busbridge wrote:
> Hi All,
>
> I have updated the slide-deck (see slides 2 to 20). These analyze the interactions between actors in the local, intra-community and cross-community settings - with the alternatives for step 2 shown in each case. The intention is to allow a comparison between step 2 alternatives to be made. The analysis only considers the approach where a single "full" manifest is returned in step 1.
>
> I have not yet drawn any conclusions and would like to leave that to the team. Please review and let me know if we should hold another meeting to discuss within the group.
>
> Some comments have already been made by Wim Corbijn and Andries Hamster. These need to be handled when we clean up the whole slide deck.

>
> Thanks,
>
> Rick
>
>
> Met vriendelijke groet,
>
> ​​*Rick Busbridge*, Specialist gegevensuitwisseling
> /Afdeling: Product O&B - Generieke Standaarden/
>
> _<http://nictiz.nl/>_
>
> Oude Middenweg 55 | 2491 AC Den Haag | _www.nictiz.nl <https://nictiz.nl/>_ | KvK 27246881
> _rick.bu...@nictiz.nl <mailto:rick.bu...@nictiz.nl>_ | _LinkedIn <https://www.linkedin.com/company/nictiz>_
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

> *From:* Rick Busbridge <rick.bu...@nictiz.nl>
> *Sent:* Wednesday, October 29, 2025 12:34
> *To:* Andries Hamster <and...@founda.com>
> *Cc:* Ho, Kinson <kins...@optum.com>; O'Donnell, Kevin <KOdo...@mru.medical.canon>; David Clunie <dcl...@dclunie.com>; Robin Breslin <rbre...@trumonix.co.uk>; Nick Hermans <nick.h...@uzleuven.be>; bas.van.d...@philips.com <bas.van.d...@philips.com>; ROBINSON, Neil (NHS ENGLAND & NHS IMPROVEMENT - X24) <neil.ro...@nhs.net>; mark....@founda.com <mark....@founda.com>; desp...@externos.sanidad.gob.es <desp...@externos.sanidad.gob.es>; ignacio....@philips.com <ignacio....@philips.com>; Josh Priebe <jpr...@epic.com>; marc.ka...@visus.com <marc.ka...@visus.com>; cha...@interopehealth.com <cha...@interopehealth.com>; Medema, Jeroen <jeroen...@philips.com>; ihe-ra...@googlegroups.com <ihe-ra...@googlegroups.com>; Corbijn van Willenswaard, Wim <wim.corbijn.va...@philips.com>
> *Subject:* Re: Why not DICOMweb query or metadata retrieval rather than extended manifest, was Re: [IHE-Rad-Tech4348] RE: Updated MADO Scenarios File
> Hi all,
>
> Please find an updated slide-deck attached. I've added some Cross-Community slides (5 to 12) to illustrate different (sub) scenarios. I will do the same for the intra-community and local settings. Have run out of time now but will work on it again later today. I haven't addressed any Andries questions directly yet.
>
> Regards,

>
> Rick
>
> Met vriendelijke groet,
>
> ​​*Rick Busbridge*, Specialist gegevensuitwisseling
> /Afdeling: Product O&B - Generieke Standaarden/

> ////
> <http://nictiz.nl/>
>
> Oude Middenweg 55 | 2491 AC Den Haag | www.nictiz.nl <https://nictiz.nl/>| KvK 27246881
> rick.bu...@nictiz.nl <mailto:rick.bu...@nictiz.nl> | LinkedIn <https://www.linkedin.com/company/nictiz>//
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Rick Busbridge <rick.bu...@nictiz.nl>
> *Sent:* Tuesday, October 28, 2025 15:12
> *To:* Andries Hamster <and...@founda.com>
> *Cc:* Ho, Kinson <kins...@optum.com>; O'Donnell, Kevin <KOdo...@mru.medical.canon>; David Clunie <dcl...@dclunie.com>; Robin Breslin <rbre...@trumonix.co.uk>; Nick Hermans <nick.h...@uzleuven.be>; bas.van.d...@philips.com <bas.van.d...@philips.com>; ROBINSON, Neil (NHS ENGLAND & NHS IMPROVEMENT - X24) <neil.ro...@nhs.net>; mark....@founda.com <mark....@founda.com>; desp...@externos.sanidad.gob.es <desp...@externos.sanidad.gob.es>; ignacio....@philips.com <ignacio....@philips.com>; Josh Priebe <jpr...@epic.com>; marc.ka...@visus.com <marc.ka...@visus.com>; cha...@interopehealth.com <cha...@interopehealth.com>; Medema, Jeroen <jeroen...@philips.com>; ihe-ra...@googlegroups.com <ihe-ra...@googlegroups.com>; Corbijn van Willenswaard, Wim <wim.corbijn.va...@philips.com>
> *Subject:* Re: Why not DICOMweb query or metadata retrieval rather than extended manifest, was Re: [IHE-Rad-Tech4348] RE: Updated MADO Scenarios File
> Hi all,
>
> Thanks Andries, David and Kevin.
>
> Can you all please wait for an updated version of the first few slides that I would like to make? I'll try to get them done by tomorrow (midday CET). There are some interesting issues coming out of these email exchanges.
>
> Until tomorrow,

>
> Rick
>
> Met vriendelijke groet,
>
> ​​*Rick Busbridge*, Specialist gegevensuitwisseling
> /Afdeling: Product O&B - Generieke Standaarden/

> ////
> <http://nictiz.nl/>
>
> Oude Middenweg 55 | 2491 AC Den Haag | www.nictiz.nl <https://nictiz.nl/>| KvK 27246881
> rick.bu...@nictiz.nl <mailto:rick.bu...@nictiz.nl> | LinkedIn <https://www.linkedin.com/company/nictiz>//
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Andries Hamster <and...@founda.com>
> *Sent:* Tuesday, October 28, 2025 15:00
> *To:* Rick Busbridge <rick.bu...@nictiz.nl>
> *Cc:* Ho, Kinson <kins...@optum.com>; O'Donnell, Kevin <KOdo...@mru.medical.canon>; David Clunie <dcl...@dclunie.com>; Robin Breslin <rbre...@trumonix.co.uk>; Nick Hermans <nick.h...@uzleuven.be>; bas.van.d...@philips.com <bas.van.d...@philips.com>; ROBINSON, Neil (NHS ENGLAND & NHS IMPROVEMENT - X24) <neil.ro...@nhs.net>; mark....@founda.com <mark....@founda.com>; desp...@externos.sanidad.gob.es <desp...@externos.sanidad.gob.es>; ignacio....@philips.com <ignacio....@philips.com>; Josh Priebe <jpr...@epic.com>; marc.ka...@visus.com <marc.ka...@visus.com>; cha...@interopehealth.com <cha...@interopehealth.com>; ihe-ra...@googlegroups.com <ihe-ra...@googlegroups.com>
> *Subject:* Re: Why not DICOMweb query or metadata retrieval rather than extended manifest, was Re: [IHE-Rad-Tech4348] RE: Updated MADO Scenarios File
> Thanks Kevin,
>
> I added my comments in the version that Rick shared
>
> Best regards,
>
> Andries Hamster

>
> On Tue, Oct 28, 2025 at 10:03 AM Rick Busbridge <rick.bu...@nictiz.nl <mailto:rick.bu...@nictiz.nl>> wrote:
>
> Hi all,
>
> I don't have access rights to update the slide-deck on the google drive. I took the latest version "*IHE MADO Scenarios-2025.10.27-CP-KOD*"**and added a question in slide 4, comment in slide 5 and a new slide 7 which shows the transactions needed if you first get the KOS and then use WADO to retrieve the KIN(s) to allow the relevant (significant image) retrieval by WADO too - this allows a comparison with slide 6.
>
> Can someone either give me update access to the google drive or save the attached slide-deck "*IHE MADO Scenarios-2025.10.28-CP-KOD-RB*" there for me?
>
> Thanks,
>
> Rick
>
> Met vriendelijke groet,
>
> ​​*Rick Busbridge*, Specialist gegevensuitwisseling
> /Afdeling: Product O&B - Generieke Standaarden/
>
> _<http://nictiz.nl/>_
>
> Oude Middenweg 55 | 2491 AC Den Haag | _www.nictiz.nl <https://nictiz.nl/>_ | KvK 27246881
> _rick.bu...@nictiz.nl <mailto:rick.bu...@nictiz.nl>_ | _LinkedIn <https://www.linkedin.com/company/nictiz>_
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

> *From:* Ho, Kinson <kins...@optum.com <mailto:kins...@optum.com>>

> *Sent:* Monday, October 27, 2025 18:18

> *To:* O'Donnell, Kevin <KOdo...@MRU.MEDICAL.CANON>; David Clunie <dcl...@dclunie.com <mailto:dcl...@dclunie.com>>; Robin Breslin <rbre...@trumonix.co.uk <mailto:rbre...@trumonix.co.uk>>
> *Cc:* Nick Hermans <nick.h...@uzleuven.be <mailto:nick.h...@uzleuven.be>>; bas.van.d...@philips.com <mailto:bas.van.d...@philips.com> <bas.van.d...@philips.com <mailto:bas.van.d...@philips.com>>; ROBINSON, Neil (NHS ENGLAND & NHS IMPROVEMENT - X24) <neil.ro...@nhs.net <mailto:neil.ro...@nhs.net>>; mark....@founda.com <mailto:mark....@founda.com> <mark....@founda.com <mailto:mark....@founda.com>>; desp...@externos.sanidad.gob.es <mailto:desp...@externos.sanidad.gob.es> <desp...@externos.sanidad.gob.es <mailto:desp...@externos.sanidad.gob.es>>; ignacio....@philips.com <mailto:ignacio....@philips.com> <ignacio....@philips.com <mailto:ignacio....@philips.com>>; Josh Priebe <jpr...@epic.com <mailto:jpr...@epic.com>>; marc.ka...@visus.com <mailto:marc.ka...@visus.com> <marc.ka...@visus.com <mailto:marc.ka...@visus.com>>; Rick Busbridge <rick.bu...@nictiz.nl
> <mailto:rick.bu...@nictiz.nl>>; Andries Hamster <and...@founda.com <mailto:and...@founda.com>>; cha...@interopehealth.com <mailto:cha...@interopehealth.com> <cha...@interopehealth.com <mailto:cha...@interopehealth.com>>; ihe-ra...@googlegroups.com <mailto:ihe-ra...@googlegroups.com> <ihe-ra...@googlegroups.com <mailto:ihe-ra...@googlegroups.com>>

> *Subject:* Re: Why not DICOMweb query or metadata retrieval rather than extended manifest, was Re: [IHE-Rad-Tech4348] RE: Updated MADO Scenarios File
>

> You don't often get email from kins...@optum.com <mailto:kins...@optum.com>. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>

>
>
> Thanks Kevin for the presentation. This is very helpful.
>
> For the cases that the Imaging Document Source is publishing multiple manifests (full/slim), additional KIN or additional metadata in manifest, we are making the following assumptions:
>

> *

> For the consumer to retrieve just the key images, the manifest / KIN / metadata ONLY tells the consumer what it may be interested. The consumer has to issue object-by-object retrieval to retrieve what is specified because there is no easy mechanism today to day ‘retrieve all objects referenced in this KIN or manifest’.

> o

> As far as my experience, most consumers retrieve the manifest and simply use the study instance UID to issue a study level retrieve, not object-by-object

> o

> This is especially true if we are considering a remote retrieval scenario in MADO.

> *

> For the source to add multiple manifests / KIN / metadata, the source knows what are relevant for all clients in all scenarios such that the clients can retrieve just the key images.

> o

> Not sure this is a reasonable assumption

> o

> If not, then we are potentially running into a potential loop that a client needs additional metadata not already published by the source; the source then adds new metadata and publishes additional manifest / KIN / metadata

> +

> What about existing manifests already published? Do we need to update them using the existing XDS mechanism?
>
>
> So it seems like by trying to have the source provide more information to the client, we are making both the source and consumer more complicated (also as stated in the presentation).
>
> Fundamentally, there is no straightforward retrieve mechanism to retrieve just the key images. I think something new needs to be introduced for this to support MADO efficiently.
>
> Furthermore, if the source can actually make this decision in the first place, then why not have the consumer simply ask the source to return key images of the study (e.g. new WADO-RS retrieve at the study level with /key-images parameter, or new DIMSE equivalent), with additional options to support different ‘key images’ in different scenarios (by study type, by client, etc.). Then no change to existing XDS-I. Simple enhancement in consumers to request key images, if needed, when retrieving the study from Imaging Document Source. Most of the work will be done by the source, which is the case anyway.
>
> Just a thought.
>
> Thanks,
>
> Kinson
>

> *From: *ihe-ra...@googlegroups.com <mailto:ihe-ra...@googlegroups.com> <ihe-ra...@googlegroups.com <mailto:ihe-ra...@googlegroups.com>> on behalf of O'Donnell, Kevin <KOdo...@MRU.MEDICAL.CANON>
> *Date: *Friday, October 24, 2025 at 10:07 PM
> *To: *David Clunie <dcl...@dclunie.com <mailto:dcl...@dclunie.com>>, Robin Breslin <rbre...@trumonix.co.uk <mailto:rbre...@trumonix.co.uk>>
> *Cc: *Nick Hermans <nick.h...@uzleuven.be <mailto:nick.h...@uzleuven.be>>, bas.van.d...@philips.com <mailto:bas.van.d...@philips.com> <bas.van.d...@philips.com <mailto:bas.van.d...@philips.com>>, ROBINSON, Neil (NHS ENGLAND & NHS IMPROVEMENT - X24) <neil.ro...@nhs.net <mailto:neil.ro...@nhs.net>>, mark....@founda.com <mailto:mark....@founda.com> <mark....@founda.com <mailto:mark....@founda.com>>, desp...@externos.sanidad.gob.es <mailto:desp...@externos.sanidad.gob.es> <desp...@externos.sanidad.gob.es <mailto:desp...@externos.sanidad.gob.es>>, ignacio....@philips.com <mailto:ignacio....@philips.com> <ignacio....@philips.com <mailto:ignacio....@philips.com>>, Josh Priebe <jpr...@epic.com <mailto:jpr...@epic.com>>, marc.ka...@visus.com <mailto:marc.ka...@visus.com> <marc.ka...@visus.com <mailto:marc.ka...@visus.com>>, Rick Busbridge <rick.bu...@nictiz.nl
> <mailto:rick.bu...@nictiz.nl>>, Andries Hamster <and...@founda.com <mailto:and...@founda.com>>, cha...@interopehealth.com <mailto:cha...@interopehealth.com> <cha...@interopehealth.com <mailto:cha...@interopehealth.com>>, ihe-ra...@googlegroups.com <mailto:ihe-ra...@googlegroups.com> <ihe-ra...@googlegroups.com <mailto:ihe-ra...@googlegroups.com>>
> *Subject: *[IHE-Rad-Tech] RE: Why not DICOMweb query or metadata retrieval rather than extended manifest, was Re: [IHE-Rad-Tech4348] RE: Updated MADO Scenarios File

> >> https://urldefense.com/v3/__https://dicom.nema.org/medical/dicom/curr <https://urldefense.com/v3/__https://dicom.nema.org/medical/dicom/curr>

> >> ent/output/html/part18.html*table_10.6.3-3__;Iw!!Ai2CFrZnFhI!6UatFBft
> >> qmcy_0CTFQq0dpFCoMJ-QrUeljLesgTiBa4S2QqDWcy5UgwxBBXE4XUF_dL4vokfmbi18
> >> 8nguujiyxD3$
> >>
> >> It really isn't that hard, e.g.:
> >>
> >> curl --insecure

> >> 'https://urldefense.com/v3/__https://ihe.j4care.com:18443/dcm4chee-ar <https://urldefense.com/v3/__https://ihe.j4care.com:18443/dcm4chee-ar>

> >> c/aets/DCM4CHEE/rs/studies?StudyInstanceUID=2.25.18915867793495056012
> >> 6618528446322890163__;!!Ai2CFrZnFhI!6UatFBftqmcy_0CTFQq0dpFCoMJ-QrUel
> >> jLesgTiBa4S2QqDWcy5UgwxBBXE4XUF_dL4vokfmbi188ngukrZT5NH$ ' | jq
> >>
> >> curl --insecure

> >> 'https://urldefense.com/v3/__https://ihe.j4care.com:18443/dcm4chee-ar <https://urldefense.com/v3/__https://ihe.j4care.com:18443/dcm4chee-ar>

> >> c/aets/DCM4CHEE/rs/studies/2.25.1891586779349505601266185284463228901
> >> 63/series?__;!!Ai2CFrZnFhI!6UatFBftqmcy_0CTFQq0dpFCoMJ-QrUeljLesgTiBa
> >> 4S2QqDWcy5UgwxBBXE4XUF_dL4vokfmbi188nguhTAd4wR$ ' | jq
> >>
> >> (though in this example Series Description is actually empty, but you
> >> see where it is returned).
> >>
> >> And if you just want all the metadata to filter client-side:
> >>
> >> curl --insecure

> >> 'https://urldefense.com/v3/__https://ihe.j4care.com:18443/dcm4chee-ar <https://urldefense.com/v3/__https://ihe.j4care.com:18443/dcm4chee-ar>

> >> c/aets/DCM4CHEE/rs/studies/2.25.1891586779349505601266185284463228901
> >> 63/metadata__;!!Ai2CFrZnFhI!6UatFBftqmcy_0CTFQq0dpFCoMJ-QrUeljLesgTiB
> >> a4S2QqDWcy5UgwxBBXE4XUF_dL4vokfmbi188nguql_3EUv$ ' | jq
> >>
> >> How hard is that?
> >>
> >> On 10/21/25 6:14 PM, charles via IHE Radiology Technical Committee wrote:
> >> > Hi,
> >> >
> >> > Thanks, Kevin for the updated slides.
> >> >
> >> > Attached and on the Google Drive an expanded and annotated version.
> >> >
> >> > Regards
> >> >
> >> > Charles Parisot
> >> >
> >> > *De :*O'Donnell, Kevin
> >> > *Envoyé :* samedi 18 octobre 2025 01:07 *À :*

> >> > cha...@interopehealth.com <mailto:cha...@interopehealth.com>; 'Andries Hamster' ; 'Rick Busbridge'

> >> > *Cc :* 'Nick Hermans' ; 'Heuvel, Bas van den' ; 'ROBINSON, Neil
> >> > (NHS ENGLAND)' ; 'Robin Breslin' ; 'Mark Sinke' ;

> >> > desp...@externos.sanidad.gob.es <mailto:desp...@externos.sanidad.gob.es>; ignacio....@philips.com <mailto:ignacio....@philips.com>;
> >> > jpr...@epic.com <mailto:jpr...@epic.com>; marc.ka...@visus.com <mailto:marc.ka...@visus.com>;
> >> > ihe-ra...@googlegroups.com <mailto:ihe-ra...@googlegroups.com> *Objet :* Updated MADO Scenarios File

> >> >
> >> > Hi Folks,
> >> >
> >> > Attached and in the Google drive are updates to the MADO Scenarios discussion file to reflect points at the meeting this week.
> >> >
> >> > Cheers,
> >> >
> >> >   Kevin
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google Groups "IHE Radiology Technical Committee" group.

> >> > To unsubscribe from this group and stop receiving emails from it, send an email to IHE-Rad-Tech...@googlegroups.com <mailto:IHE-Rad-Tech%2Bunsu...@googlegroups.com> .
> >> > To view this discussion visit https://urldefense.com/v3/__https://groups.google.com/d/msgid/IHE-Rad-Tech/a47f01dc42d8*2423708ca0*246a51a5e0*24*40interopehealth.com__;JSUlJQ!!Ai2CFrZnFhI!6UatFBftqmcy_0CTFQq0dpFCoMJ-QrUeljLesgTiBa4S2QqDWcy5UgwxBBXE4XUF_dL4vokfmbi188ngukTfL3Xo$ <https://urldefense.com/v3/__https://groups.google.com/d/msgid/IHE-Rad-Tech/a47f01dc42d8*2423708ca0*246a51a5e0*24*40interopehealth.com__;JSUlJQ!!Ai2CFrZnFhI!6UatFBftqmcy_0CTFQq0dpFCoMJ-QrUeljLesgTiBa4S2QqDWcy5UgwxBBXE4XUF_dL4vokfmbi188ngukTfL3Xo$>  .

> >>
>
> --
> You received this message because you are subscribed to the Google Groups "IHE Radiology Technical Committee" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to IHE-Rad-Tech...@googlegroups.com <mailto:IHE-Rad-Tech%2Bunsu...@googlegroups.com>.
> To view this discussion visit https://urldefense.com/v3/__https://groups.google.com/d/msgid/IHE-Rad-Tech/LV8PR18MB5679C725A78208F7BABF099DFCFEA*40LV8PR18MB5679.namprd18.prod.outlook.com__;JQ!!IqUcNYopQPk7!PiwUI7JBgZzqeWZi_EGddhjnqr1mxCaQ6p4MFXdTOUKFB3dSgHloBqKrJ6FWNWZblUK7tvURxQLxR-SnSsng1LJYaAk$ <https://urldefense.com/v3/__https://groups.google.com/d/msgid/IHE-Rad-Tech/LV8PR18MB5679C725A78208F7BABF099DFCFEA*40LV8PR18MB5679.namprd18.prod.outlook.com__;JQ!!IqUcNYopQPk7!PiwUI7JBgZzqeWZi_EGddhjnqr1mxCaQ6p4MFXdTOUKFB3dSgHloBqKrJ6FWNWZblUK7tvURxQLxR-SnSsng1LJYaAk$> .

[David Clunie]

Hi Rick ... vide infra ...

On 10/31/25 9:50 AM, Rick Busbridge wrote:

> In theory, an XC-QIDO could be developed too but there seems to be some resistance. A number of issues arise:
>
> 1.
> Source systems not wanting to be quired from "unknown" external consumers. Healthcare providers are very reluctant to allow such query capability.

If they don't want to be "queried" from outside, then they probably shouldn't allow viewing
either, and certainly not from "unknown" external consumers - there should not be any access
by anyone "unknown" who has not been authenticated and approved (zero-trust principle), IFNOR
WADO exposes too much about the subject to allow unrestricted access.

That applies to any sharing that is a pull rather than push (and one shouldn't be pushing to
unknown unapproved third parties either).

Also, I am not sure that providing WADO without QIDO is actually PS3.18 compliant.

> 2. Danger of too much information being exposed - if a query is allowed, who is to say, for example, which metadata parts of an imaging study may be returned. With the manifest approach, the source HP has decided what will be published to the outside world and what remains internal.

If viewing is allowed, all the metadata is exposed, of which the query result sets are a
subset. So, WADO is even more of a risk in terms of information disclosure than QIDO in
this respect.

"Selective publishing" in this context seems to be "security through obscurity", which
is not secure at all.

End-point access needs also be filtered server-side to restrict access to only what "the source
... has decided what will be published to the outside world", if needed (i.e., exposed QIDO and
WADO end points alike should not allow unconstrained access, if not explicitly authorized).

> 3. Issues with patient identity (and access tokens authorized against a given id). QIDO uses the primary patient id defined in the consumer system as the patient level query key. This is unlikely to match the patient id used in a remote (cross-community) system. So how should be patient id mapping be handled (and then the access tokens updated) in such a case? Effectively the mapping has to be undone in the patient level query responses as the responses travel back through the gateways. I realize that an agreement could be reached to use a common (national) identifier but that needs to be well specified in any kind of XC-QIDO approach.

That applies to all the relevant identifiers, etc., for viewing and querying - either you
have a mapping and access mechanism, and apply it in the gateways or you don't.

But isn't the patient identifier irrelevant, since the QIDO is based on the DICOM Study Instance UID
from the (non-extended) manifest so you already know it, right?

> As far as I'm aware no one has yet seen the need for an XC-QIDO

Well, this use case seems to be demonstrating a need for a "XC-QIDO" (or a limited subset
thereof).

Since MADO is a new proposal, it seems reasonable to consider XC-QIDO as a valid mechanism,
even if also "new".

BTW. has there been attention paid to the practicality and scalability of securing the WADO
end point at the Source Gateway or the Source PACS, which seems fundamental to the use case?

The current XC-WADO text [1], which would be equally applicable to any "XC-QIDO" deployment,
has some discussion in "58.5 XC-WADO Security Considerations" that leaves "user authentication
and authorization methods ... outside the scope", mentions the use of EUA and IUA, but doesn't
really address the scalability, especially in a cross-border setting.

How are these being resolved by your activities in the EHDS context?

David

1. https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD-Suppl_XC-WADO.pdf

[cha...@interopehealth.com]

David and Rick,

I was reviewing the e-mail exchange between David and Rick.

A couple clarifications you might find relevant to the points discussed, in particular about:

"this is back to my original point that if you can do WADO you can do QIDO, so you don't need an extended manifest if you have QIDO."

1 - Critical differences between WADO and QIDO: WADO is study specific. Not all studies for a patient are accessible. QIDO is capable across patients and studies, which is manageable within a provider, but would require additional control and restrictions.
2 - QIDO would need its imaging specific "registry" at the national/regional levels, as in most countries there exist a large number of imaging sources, where image are stored, that are unlikely to welcome the processing of QIDO broadcasts. A manifest being a document like many other, its discovery/filter is handled in the same way and except for a couple search parameters would not require any imaging specifics, making imaging more welcome and easier to deploy.
3- Reducing the number of exposed endpoints that receive requests is important. This double them, thus complexifies look-up services, and URL management operational processes.

Regards
Charles

-----Message d'origine-----
De : ihe-ra...@googlegroups.com <ihe-ra...@googlegroups.com> De la part de David Clunie
Envoyé : vendredi 31 octobre 2025 14:13
À : Rick Busbridge <rick.bu...@nictiz.nl>
Cc : Ho, Kinson <kins...@optum.com>; O'Donnell, Kevin <KOdo...@mru.medical.canon>; Robin Breslin <rbre...@trumonix.co.uk>; Nick Hermans <nick.h...@uzleuven.be>; bas.van.d...@philips.com; ROBINSON, Neil (NHS ENGLAND & NHS IMPROVEMENT - X24) <neil.ro...@nhs.net>; mark....@founda.com; desp...@externos.sanidad.gob.es; ignacio....@philips.com; Josh Priebe <jpr...@epic.com>; marc.ka...@visus.com; cha...@interopehealth.com; Medema, Jeroen <jeroen...@philips.com>; ihe-ra...@googlegroups.com; Corbijn van Willenswaard, Wim <wim.corbijn.va...@philips.com>; Andries Hamster <and...@founda.com>
Objet : [IHE-Rad-Tech] Re: Why not DICOMweb query or metadata retrieval rather than extended manifest, was Re: [IHE-Rad-Tech4348] RE: Updated MADO Scenarios File

To unsubscribe from this group and stop receiving emails from it, send an email to IHE-Rad-Tech...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/IHE-Rad-Tech/0100019a3a663f09-1eb5c94c-000a-4dd2-9b0e-8337f93e4207-000000%40email.amazonses.com.

[David Clunie]

Hi Charles

On 11/1/25 10:56 AM, cha...@interopehealth.com wrote:

> 1 - Critical differences between WADO and QIDO: WADO is study specific. Not all studies for a patient are accessible. QIDO is capable across patients and studies, which is manageable within a provider, but would require additional control and restrictions.

Actually both QIDO and WADO are "study specific" - that's why they are defined in the
"10 Studies Service and Resources" section of PS3.18, and their resources are ".../studies".

Patient attributes are attributes of the Study IE in this service (just like the PS3.4
Study Root C-FIND).

That said, certainly any provider-identity or attribute-based access control mechanism
on any exposed end-point would certainly have to filter the response to any QIDO or
WADO request similarly, to whatever level of access had been granted for a specific study
or whatever other level of granularity was necessary, I agree (whether the provider had
granted access at the patient-level or study-level if modeled as such, or based on any
other criteria).

And certainly control is necessary as you suggest, since even though the resources are
study-based, the queries can be by patient attributes across multiple studies, and as
a practical matter, generalized queries are often constrained by origin servers anyway,
for resource constraint reasons.

> 2 - QIDO would need its imaging specific "registry" at the national/regional levels, as in most countries there exist a large number of imaging sources, where image are stored, that are unlikely to welcome the processing of QIDO broadcasts. A manifest being a document like many other, its discovery/filter is handled in the same way and except for a couple search parameters would not require any imaging specifics, making imaging more welcome and easier to deploy.

Not sure that I understand this.

There isn't a difference between knowing the QIDO end-point and knowing the WADO end-point
when it comes to registry requirements - either you know where (end-point) the images are
to view AND query, or you don't (e.g., from the Retrieve URL of the Study in the KOS, i
present and if not pre-configured).

QIDO is not a "broadcast", but I assume you are meaning imaging sources getting queries from
lots of places, which I am suggesting is not any different from getting viewing requests from
lots of places.

I am not arguing against registering manifests in a registry, just what comes next for the
further sub-selection of what was already registered.

> 3- Reducing the number of exposed endpoints that receive requests is important. This double them, thus complexifies look-up services, and URL management operational processes.

The QIDO and WADO end-points are the same - i.e., "The Base URI of the Studies Service"
per PS3.18 Table 10.1-1, they are just different transactions on the same resource.

That said, I don't disagree that the same access-control restrictions need to be
replicated across multiple transactions, and across multiple sub-resources, but
one has to do that in any deployment that supports access control of any kind,
including local zero trust scenarios.

Anyway, if you are wondering why I am persisting with this discussion, it is because if one
is going to have a distributed access control mechanism in place at all (which seems necessary
for accessing, say, FHIR resources in a distributed cross-community manner), then using the
same mechanism for (a) zero trust control of local as well as remote access, and (b) using
the same mechanism for control of image query and retrieval access, would seem to make sense.

Or to put it another way, you aren't doubling the work, you are reusing the work you already
had to do to control local access and within-community remote access, just leveraging the
extension of the identity realm to a cross-community scenario, which you need to do anyway
for viewing, don't you? An imaging source can't just let "anybody" view images, just
because they know the end-point and the Study Instance UID.

I am still interested to know how, in the scope of the EHDS, access control across communities
is being handled, irrespective of what is decided about on which information to sub-select
imaging studies.

I dare say even access to a registry in the first place needs to be similarly controlled
and filtered, and certainly retrieval of "documents" including any "manifest", right?

And, I understand, in EHDS patients will have access, and be able to micro-manage who else
has access - how is that being implemented?

David