• Beste gast, wij willen dit platform constant verbeteren maar hebben daarbij jouw hulp nodig!
    Wil je een paar minuten van je tijd spenderen aan deze korte enquête?

WADO-WS vs WADO-RS

Igor Schoonbrood

Active member
Ambassadeur
Organisatie
MUMC+
Ik heb een vraag over WADO-WS en WADO-RS,


Zoals jullie wellicht weten zijn er in Nederland voor XDS 2 dominante leveranciers. Philips (voorheen Forecare en Enovation). Deze 2 leveranciers hebben samen met Nexus een TA beschreven voor een Nederlands brede HIE Netwerk (XDS).

In deze TA (Zie 1) staat beschreven (op pagina 5) dat er optioneel gebruikt kan worden van Wado-WS. Dit omdat er behoefte is om lossy compressed images van XCA-I te versturen. Deze standaard wordt met name gebruikt om Thumbnail te tonen in de tijdlijn van de gebruiker. Een belangrijke functionaliteit. Hiermee kan de arts/radioloog een preview zien, zonder de hele studie over te halen.



Nu lopen wij in ons ziekenhuis tegen de volgende situatie aan:



Wij hebben als XDS leverancier Hyland. Hyland is gekoppeld aan de Enovation-hub en via deze hub is Philips te bereiken. Via deze constructie is ons buur ziekenhuis Zuyderland (klant van Philips) te bereiken en kunnen beelden uitgewisseld worden, met voor als het nu lijkt een acceptabele performance.

We stuiten nu echter wel op de volgende probleem en dat is de tijdlijn functie waarin Thumbnail getoond moeten worden. Onze leverancier support Wado-WS niet en dan mentame de Retrieve Rendered Imaging Document Set transactie

. Wado WS is in 2017 door Dicom als retired bestempeld (Zie 3) . Wado-Ws is op een “verouderd” en langzamer protocol SOAP gebaseerd. De standaard WADO-RS vervangt deze oude standaard en is gebaseerd op RESTFull. Onze leverancier ondersteund WADO-RS en voldoet dus aan alle internationale specs en eisen, maar niet aan de Nederlandse TA.

Philips heeft aangegeven geen resources beschikbaar te hebben om WADO-RS te implementeren.

Onze leverancier wilt geen standaard inbouwen die alleen voor Nederland nodig zijn en die al in 2017 als retired bestempeld is.

Daar de tumbhnails een belangrijk onderdeel is in de uitwisseling en we geen optimaal proces met zuyderland kunnen inrichten zitten we hier in een pad stelling. Het lijkt erop dat onze leveranciers door het schrijven van deze leverancier de Nederlandse markt op slot hebben gezet. Want welke buitenlandse leverancier wilt specifiek voor Nederland een oude standaard implementeren.



Hoe moet ik hier nu mee omgaan? Ik hoor graag van jullie een advies.

1) https://taskforce-samen-vooruit.nl/...Nationaal-Technische-Afspraak-version-1.1.pdf

2) https://en.wikipedia.org/wiki/DICOMweb

3) https://dicom.nema.org/Dicom/News/June2017/docs/sups/sup198.pdf
 
Hoi Igor,

Mijn eerste ingeving is de volgende.
Aangezien WADO WS al sinds 2017 Retired is, mogen we niet verlangen dat Hyland die nog voor de Nederlandse markt gaat inbouwen.
Wat we wel mogen verwachten is dat onze XDS leveranciers hun product up-to-date houden en met internationale (DICOM) ontwikkelingen meegaan. Dat heeft Philips blijkbaar al sinds 2017 niet gedaan en ik denk dat je mag stellen dat ze daarmee hun plicht als leverancier hebben verzaakt. (Hoe zit dat met Enovation?).
Momenteel komt daar nog bij dat Philips in zwaar weer zit en bezig is de XDS productontwikkeling over te brengen naar India. Laurens Pronk heeft ons kort geleden bijgepraat en verteld dat dit o.a. betekent dat de XDS ontwikkelingen de komende 1,5 jaar vrijwel stil komen te liggen, i.v.m. kennisoverdracht naar India en het volledig doorlichten van de huidige XDS-software. Daarmee is een korte termijn oplossing, in de vorm van ondersteuning van WADO RS door Philips, niet in zicht.

Toch vind ik dat wij als Nederlandse klanten, hierin gezamenlijk zouden moeten optrekken en alsnog met klem moeten vragen om implementatie van WADO RS op zo kort mogelijke termijn. Een vorm van vraagbundeling dus. Ik wil me vanuit het UMC Utrecht wel hard maken om zo'n vraag vanuit de Philips klanten te ondersteunen.
Lukt dit niet, dan is de vraag of er een (technische) list is te verzinnen om de gewenste tijdlijn alsnog (via een tijdelijke oplossing?) te realiseren zonder WADO RS?

Groet,
Sjaak
 
Wij zijn mogelijk (gedeeltelijk) aanstichter van deze ervaren problematiek, waarvoor bij voorbaat excuses. Maar het is geboren uit pragmatiek...

Wat achtergrond
Toen wij begin 2018 bezig waren met de implementatie van ons Forcare XDS platform, was er binnen de IHE-XDS specificatie geen mogelijkheid om DICOM beelden op een snelle wijze beschikbaar te maken over een XCA-gateway (louter RAD-69 - alleen complete DICOM beelden). Dit leverde zoals je ook stelt een aantal problemen op wanneer een snelle triage van beelden noodzakelijk is, bijvoorbeeld in het geval van CVA patiënten.

De DICOM foundation (dus niet: IHE) ‘onderhield’ tot medio 2017 een uitbreiding hierop om ook bijvoorbeeld JPEGs (waarbij je als client zaken als afmetingen kunt specificeren) te transporteren. Omdat er in DICOM weinig draagvlak voor was en er veel fouten in de standaard zaten, hebben ze deze uiteindelijk geschrapt / deprecated gemaakt. Wij zagen desondanks de toepassing van WADO-WS als enige mogelijke oplossing voor dit probleem en hebben de toen drie grootste XDS leveranciers van het land (Vanad Enovation, Meddex, Forcare) gevraagd om dit in te bouwen in hun producten én voor te dragen bij IHE om op te nemen in de standaard (daar bleek helaas weinig draagvlak voor te zijn). Met toepassing van deze 'standaard' zou het mogelijk zijn om op verzoek van de ontvanger, beelden aan de bron te vertalen in JPG-formaat om deze vervolgens snel en per serie, te versturen. Een client hoeft dan zelf geen DICOM-processing meer te doen, maar kan gelijk een JPEG ophalen.

In de tweede helft van 2017 hebben deze leveranciers gezamenlijk afgesproken om – bij gebrek aan een alternatieve technologie - deze toepassing van WADO-WS over XCA te gaan ondersteunen in hun producten, teneinde de functionele vraag vanuit de zorg voorop te zetten en klanten zo goed mogelijk te kunnen ondersteunen. Dave Franken (toen: Meddex) en Mark Sinke / Walco van Loon (Forcare) waren er toen nauw bij betrokken. Uiteindelijk - het heeft even wat geduw en getrek nodig gehad - hebben we dit werkend gekregen tussen de verschillende providers en is het onderdeel geworden van de 'standaard code-base' bij zowel Enovation als Forcare/Philips.

Het streven is altijd geweest om zodra er een beter ondersteunde standaard werd ontwikkeld die dezelfde functionaliteit huisvest, hier alsnog op over te stappen.

Hier & nu
De situatie met Philips is natuurlijk een doorn in het oog van velen van ons. Productontwikkeling lijkt überhaupt te zijn gestagneerd en de laatste berichten zoals @SjaakGondelach die schetst maken dat we niet veel van hun hoeven te verwachten.

Ik weet overigens niet of Dicomweb (QIDO-RS, WADO-RS) wel een plek heeft binnen het IHE XDSi profiel. Volgens mij zijn dit DICOM standaarden net als WADO-WS was, en ervaren deze in die zin hetzelfde probleem als destijds met WADO-WS. Maar er is vast iemand die net een slag dieper in de profielen zit :) . In feite zou het slimmer zijn om deze restfull standaarden toe te passen in plaats van het oude uri variant, maar evengoed zit het dan daarmee nog niet in het IHE profiel.

Het standpunt van Hyland is begrijpelijk - zij hebben een internationale markt te voorzien en zouden hun product te zeer laten afwijken. Tegelijkertijd zitten er ook in NilRead wel enkele vendor-specifieke configuratie afwijkingen, dus a) pragmatisch het gebruik van Dicomweb introduceren bij alle partijen als vervanging van WADO-WS bij XCA transacties en b) mocht het er nog geen onderdeel van blijken te zijn, partijen gezamenlijk bewegen om een nieuwe poging te doen het IHE profiel hierop uit te breiden? Dan is dat de stip die maakt dat ook Hyland (vooruitlopend) conformeert aan internationale standaard profielen. En omdat productontwikkeling op korte termijn niet te verwachten valt bij sommige partijen, c) WADO-WS als legacy optie te laten ondersteunen totdat Dicomweb in het IHE profiel zit?

Long shot :-(

Ik ben overigens ook sterk voor vraagbundeling dus als we die zuiver kunnen formuleren doen we graag mee!
 
Laatst bewerkt:
Wat Laurens hierboven typt kan ik beamen. Hieronder mijn bijdrage in deze kennisdeling.

Let wel dat we het hier enkel hebben om WADO-WS/Rendered. WADO-WS bevat namelijk ook de reguliere RAD-69 transactie.

De hiervoor genoemde WADO-WS was/is bedoeld om rendered images op te halen, JPEG-representaties. Dit kon niet met WADO-URI die gebruikt werd binnen een XDS-omgeving, en RAD-69 kan - zoals Laurens ook toelicht - enkel 'full DICOM' transporteren.

Een bijkomend voordeel van WADO-WS is het gebruik van een SAML-token voor onder andere de gebruikersidentiteit. Voor de volledigheid; WADO-WS bestaat uit drie transacties:
  1. RetrieveImagingDocumentSet (= de bekende RAD-69)
    This action retrieves a set of DICOM instances and other objects. This action corresponds to the IHE XDS-I.b transaction RAD-69. The DICOM instances are formatted in accordance with PS3.10, and encapsulated in a Web Services response.
  2. RetrieveRenderedImagingDocumentSet (= waar het "probleem" zit)
    This action retrieves a set of DICOM instances that have been rendered into the requested format. For example, if rendering into JPEG was requested, these will be the JPEG renderings of the requested set of DICOM objects.
  3. RetrieveImagingDocumentSetMetadata
    This action retrieves a set of DICOM instances presented as an Infoset with the bulk data removed. This service can retrieve either the full metadata, or a subset selected by XPath arguments. The XML encoding for the DICOM attributes is defined in PS3.19.
WADO-WS (met de drie transacties) was destijds inderdaad deprecated, waarbij de RAD-69 transactie is geadopteerd door IHE/RAD-domein. Dit geldt enkel voor de specifieke RetrieveImagingDocumentSet. Doordat de RetrieveRenderedImagingDocumentSet niet werd onderhouden en 'slecht' gedocumenteerd was hebben de leveranciers dit samen opgepakt en gedocumenteerd op Github (https://github.com/watzo/ihe-wadows-2017). Daarbij heeft Dave nog een poging gewaagd om dit in te brengen bij het Radiology domain (https://wiki.ihe.net/index.php/WADO-WS_Extensions_for_XDS-I.b_and_XCA-I)

Een bijkomend voordeel van de RetrieveRenderedImagingDocumentSet is dat het mogelijk werd om een SAML-token mee te sturen met de gebruikersidentiteit (IHE XUA / ITI-40). Net zoals bij de andere XDS/XCA-transacties.

Dat WADO-RS toen al bestond betekent nog niet dat deze ook toepasbaar is, er was nog geen brede support voor deze standaard. Er is een reden dat 'adapters' worden ingezet die DICOM DIMSE praten met het PACS om zo beelden beschikbaar te maken via webservices.

Fastforward naar 2023

Is WADO-RS al breed ondersteund binnen de verschillende PACS-implementaties? Dit kan worden geïnventariseerd aan de hand van de DICOM conformance statements. Het "overstappen" op WADO-RS kan wel andere problemen introduceren. WADO-RS is geen onderdeel van het IHE XDS-I en XCA-I profiel, (wel van IHE WIA). Wellicht kan de vraag voorgelegd worden bij het radiologie en ITI infrastructuur domein van IHE. IHE WIA beschrijft namelijk hoe je met WADO-RS naar een XDS-I omgeving kan communiceren.

Een alternatief zou kunnen zijn om te kijken of de huidige XCA-I leveranciers (de leveranciers van de gateway) WADO-RS kunnen ondersteunen. Dit kan bijvoorbeeld worden gedaan door tussen gateways IHE XCA-I te hanteren (inclusief WADO-WS/rendered) en achter de gateway WADO-RS te gebruiken. Wellicht kan Enovation iets betekenen in deze, gezien Igor aangeeft dat Hyland verbonden is met Enovation gateway.

p.s. In andere delen van het land wordt de rendered jpeg getoond aan niet-radiologen buiten de zorginstelling. Laten we deze toepassing niet vergeten.
 
Bedankt allemaal voor jullie reacties.
Inmiddels lijkt Hyland met een oplossing te komen, zodat ook wij wado-ws rendering zullen gaan ondersteunen.

Wat over blijft is hoe we dit in toekomst moeten aanpakken. Laurens en Sjaak beschrijven de optie van bundeling en samen naar leveranciers to stappen. Pascal geeft daarnaast aan ihe profielen te laten aanpassen. Allemaal goede ideeen. Maar wie wordt hier de penvoerder/trekker van. Waar is startpunt. Zouden we hier eens over kunnen nadenken. Eventueel met ihe en leveranciers erbij?

Iig heel hartelijk dank dat jullie meedenken. Geeft dit platform toch waarde ;-)
 
Terug
Bovenaan