RE: Review Of MADO Draft call
cha...@interopehealth.com
Dear IHE RAD Committee members,
To help you prepare the joint t-con with the Xt-EHR WP 7.2 and the IHE-HL7 Europe Imaging Team due for September 18th from 16h00 to 18h00 (See below for the calling info) here is the current draft of the future MADO Profile on which we would like to get your feedback.
The goal of this t-con is to share with you the work we did so far on the MADO Profile, work which is in line with the submitted new work item for the 2025-2025 IHE Rad cycle. We believe that it is important to ensure that the MADO draft version that will be widely circulated in Europe as part of the Xt-EHR public consultation in support of the European Health Data Space (EHDS), due to be issued on September 28th includes as much as possible your input.
We realize that we are anticipating the IHE Rad Planning Committee approval for the MADO work item which is to be formalized on October 1st. The attached MADO Profile draft is aligned with the detailed profile proposal we submitted in August and the effort evaluation that has been completed with your support in the past two weeks.
We appreciate your feedback very much on this attached draft which is not quite ready to be issued for the IHE Public Comment (this is planned at the IHE Rad Tech Committee meeting early November). By enhancing its maturity, this should ensure that the comments collected in Europe in October/November and those collected internationally with the IHE RAD Public Comment in November/December can be resolved jointly to facilitate reaching an IHE MADO trial implementation version by January 2026, that is internationally approved.
Looking forward to constructive discussions with you on Thursday.
Regards
Charles Parisot
-----Rendez-vous d'origine-----
De : TeRhonda McGee <tmc...@rsna.org>
Envoyé : mercredi 3 septembre 2025 17:13
À : TeRhonda McGee; Jamie Dulkowski; Christopher Carr; 'Jason Nagels'; mhussain; David Kwan; Schroeder, Antje; Harald Zachmann; 'Andrei Leontiev'; Corbijn van Willenswaard, Wim; Kinson Ho; O'Donnell, Kevin; Nichols, Steve; Bialecki, Brian; Charles Parisot; maria...@outlook.com; graeme...@bayer.com; radiolog...@ihe.net; ana.kost...@philips.com
Objet : Review Of MADO Draft call
Date : jeudi 18 septembre 2025 09:00-11:00 (UTC-06:00) Centre (É.-U. et Canada).
Où : https://rsna-org.zoom.us/j/85261857623?pwd=RuveXcAgZ0hMDdkHrqoxYVgKHzcQY3.1&from=addon
| |||||||||||||||||||||||||||||
Radiological Society of North America
820 Jorie Blvd, Oak Brook, IL 60523
TEL 1-630-571-2670
FAX 1-630-571-7837
RSNA.org
Facebook
X (formerly Twitter)
Become a member
RSNA.org/Membership
David Clunie
A took a quick look:
- I don't think you should be embedding end-points like URLs in a KOS - the KOS currently
identifies instances by their UIDs and the base end-point for their retrieval should be
known and configured (that said, at the series level, there is a standard way of doing
this if you must, I just think relying on it is perhaps not a great practice, since it
triggers the need for URL re-writing in proxy/gateway cases)
- I don't think you should be messing with adding (rather than making required or conditional)
attributes within the KOS IOD - e.g., making Issuer... required rather than optional is fine,
but adding a new nested Content Sequence attribute within Referenced SOP Sequence (within the
Hierarchical SOP Instance Reference Macro that you have instantiated in your table) to a list
of unconstrained name-value pairs is definitely not fine; it circumvents the design of the IOD
and the corresponding SR template since the latter is where such content is supposed to go -
you are essentially making up an extended SOP class that will not leverage any of the standard
DICOM mechanisms for handling referenced instances in a KOS
I.e., everything highlighted in green or purple described as "Significant Images" is bad,
and undermines the intent of having a generic KOS IOD and any metadata being in the template.
David
On 9/16/25 8:35 PM, charles via Radiology Comments wrote:
> Dear IHE RAD Committee members,
>
>
> The goal of this t-con is to share with you the work we did so far on the *MADO Profile, work which is in line with the submitted new work item for the 2025-2025 IHE Rad cycle*. We believe that it is important to ensure that the MADO draft version that will be widely circulated in Europe as part of the Xt-EHR public consultation in support of the European Health Data Space (EHDS), due to be issued on September 28^th includes as much as possible your input.
>
> We realize that we are anticipating the IHE Rad Planning Committee approval for the MADO work item which is to be formalized on October 1^st . The attached MADO Profile draft is aligned with the detailed profile proposal we submitted in August and the effort evaluation that has been completed with your support in the past two weeks.
cha...@interopehealth.com
Thanks for taking the time to look and sharing your feedback. There are some points that definitively should be improved in the design of the future MADO Profile.
On the points you raise, the challenge often dates back from decisions accepted in the context of the XDS-I Profile and now widely deployed. So it seems to me that we have to include in the analysis, not only design elements specific to the KOS and its template, but also the operational deployments that are our first deployment customers and have learn to trust DICOM for its stability and pragmatism.
URL rewriting and bridging communities with different end-point management strategies is something we need to try to avoid or minimize complexity. This has been analyzed by the XC-WADO profile and solved by engaging the imaging document consumers rather than modifying the addressing content of Manifests. This is not only applicable to Retrieve URLs, but also to Retrieve Location UIDs, thus avoiding the use of URL in Manifest does not solves the problem. We have identified legitimate business cases where using retrieve URL is preferable to using Retrieve Location UIDs hence the XC-WADO and now MADO design where both will be supported in the Manifests. You point is indeed a challenge. I am intrigued with your comment: " that said, at the series level, there is a standard way of doing this if you must". It would be great to have more details, because it was the goal to align with good practices.
On you points on the "extensions" made to the KOS, less invasive ways to do those is definitively welcome. We introduced : " a new nested Content Sequence attribute within Referenced SOP Sequence (within the Hierarchical SOP Instance Reference Macro that you have instantiated in your table) to a list of unconstrained name-value pairs is definitely not fine; it circumvents the design of the IOD", is definitively an area where we intentionally introduced this "nested content sequence" to better align with the design of DICOM. Obviously, this was not the right choice. We will gladly remove such a content sequence and go back to standard extended attributes.
On the significant images, it has become clear to actual implementers that this information was needed within the imaging study manifest to make the WADO-RS retrieve of only key images flagged by a KOS (used as a KIN), effective in term of response time to the clinician. It is clear that it extends the use of KOS beyond its initial intended use, but as the creation of a Manifest based on KOS is clearly in scope, we are at a point where we have to reconcile these two positions, given that practical deployment has shown the value of KOS as a manifest to use DICOM addressing mechanisms. We also wanted to make sure, that if no significant images are flagged by one or more KIN within a study, we are as backward compatible as much as possible with the current deployment that have millions of KOS Manifests available. We certainly welcome your help in trying to better triangulate these constraints.
We may not have the time to address all of your comments in this draft, but we definitively want to use the time between now and the release of the IHE public comment version, as well as use the public comment period to work those issues out as best as possible.
Thanks so much.
Charles
-----Message d'origine-----
De : David Clunie <dcl...@dclunie.com>
Envoyé : mercredi 17 septembre 2025 12:17
À : cha...@interopehealth.com; 'TeRhonda McGee' <tmc...@rsna.org>; 'Jamie Dulkowski' <jdulk...@rsna.org>; 'Christopher Carr' <cc...@rsna.org>; 'Jason Nagels' <ja...@nagelsconsulting.com>; 'mhussain' <mhus...@techiemaestro.com>; 'David Kwan' <da...@insygniaconsulting.com>; 'Schroeder, Antje' <aschr...@siemens-healthineers.com>; 'Harald Zachmann' <harald....@merative.com>; 'Andrei Leontiev' <aleo...@visageimaging.com>; 'Corbijn van Willenswaard, Wim' <wim.corbijn.va...@philips.com>; 'Kinson Ho' <kinson...@gmail.com>; 'O'Donnell, Kevin' <kodo...@mru.medical.canon>; 'Nichols, Steve' <steven....@gehealthcare.com>; 'Bialecki, Brian' <bbia...@acr.org>; maria...@outlook.com; graeme...@bayer.com; radiolog...@ihe.net; ana.kost...@philips.com
Cc : 'Rick Busbridge' <rick.bu...@nictiz.nl>; bodi....@okfo.gov.hu; Gwenaell...@esante.gouv.fr; desp...@externos.sanidad.gob.es; mmat...@externos.sanidad.gob.es; silvia....@sigmasoft.at; Emmanu...@elga.gv.at; 'ESR - Bellemo Arianna' <arianna...@myesr.org>; ihe-eur...@googlegroups.com; Espen...@ehalsomyndigheten.se; 'Bennie Assink' <bennie...@nictiz.nl>; 'Mathieu BAJAT' <Mathie...@esante.gouv.fr>; 'Bo Rønne' <Bo.R...@regionh.dk>; 'Shubham Gopal' <shubha...@regionh.dk>; 'CASSIDY, Clare (NHS ENGLAND - X24)' <clare....@nhs.net>; andreas....@siemens-healthineers.com; lapo.b...@dedalus.eu; 'Jan Hůlek' <jan....@outlook.cz>; janos....@gehealthcare.com; 'Bruno Laffin' <bruno....@agfa.com>
Objet : Re: [radiologycomments:202] RE: Review Of MADO Draft call