Nieuwsbrief - Juli 2025 🇳🇱
Terwijl de zon volop schijnt en velen van ons genieten van een welverdiende vakantie, hebben wij een aantal interessante topics te delen. Of je nu op het strand ligt of nog even doorwerkt: deze nieuwsbrief biedt je een frisse dosis inspiratie.
Veel leesplezier!
PACS2 aansluiting in Elkerliek Ziekenhuis succesvol in gebruik.
Het Elkerliek Ziekenhuis werkt al jaren met het JiveX PACS voor alle niet-radiologische beelden. In totaal zijn er 36 specialismen in het ziekenhuis die als onderdeel van het zorgproces beelden maken die in JiveX centraal worden opgeslagen. De wens van het Elkerliek Ziekenhuis was om alle deze beelden ook beschikbaar te maken voor andere zorginstellingen via de XDSCloud. Om dit mogelijk te maken is een project gestart, waarin de volgende activiteiten zijn uitgevoerd:
- Opstellen van het Design Document:
- Vaststellen van de metadata en ophalen van input van de afdelingen waar de beelden gemaakt worden;
- De publicatie van beelden wordt gedaan middels een HL7 ORU Image Availability Notification bericht (update of deprecate);
- Voorbereiding implementatie aan PACS en XDS kant:
- Netwerk voorbereiden op nieuwe koppeling naar het PACS;
- Bespreken test cases en maken van testscript;
- Testen op acceptatie, waarbij learnings ook naar de productie worden overgezet:
- Denk hierbij bijvoorbeeld aan de encoding die gebruikt wordt voor speciale tekens in auteurnamen;
- Testen in productie, met een ander op de XDSCloud aangesloten ziekenhuis;
- Go live begeleiding.
In onderstaande afbeelding zijn de onderzoeken van één patiënt te zien waarbij de bron zowel het radiologisch PACS als het aangesloten PACS2 is.
In bovenstaande afbeelding is de weergave van een geselecteerd beeld te zien
De belangrijkste lessen van deze implementatie onder elkaar:
- Een directe lijn via een support kanaal met de PACS leverancier voor extra hulp bespoedigd de doorlooptijd van het project;
- Belangrijk om tijdig een andere zorgorganisatie te betrekken, dit met name voor testdoeleinden;
- Voor het project zijn diverse mensen uit een organisatie nodig, denk hierbij aan:
- Project manager;
- Netwerkbeheerder (begin in project voor openzetten nieuwe connecties PACS <> XDS en broker/Cloverleaf naar XDS);
- Cloverleaf / integratie specialist;
- PACS beheerder;
- Testcoördinator die vanuit het EPD en PACS handelingen kan uitvoeren.
- Metadata: Bedenk een standaard voor het definiëren van de afdeling, in dit geval zijn er SNOMED CT codes gebruikt;
- In voorbereiding op het project, denk na over eventuele migratie van historie: Is dit gewenst en zo ja, voor welke periode;
- Interne communicatie in het ziekenhuis: betrek de zorg bij het project, bijvoorbeeld via het intranet of andere beschikbare interne communicatiekanalen;
- Communicatie naar de regio: Elkerliek ziekenhuis heeft de belangrijkste samenwerkingspartners in de regio tijdig geïnformeerd;
- Doorlooptijd project van start tot go-live in 10 weken.
Vanuit Founda hebben wij ervaring met de aansluiting van vrijwel alle PACS(2) oplossingen. Heeft jouw organisatie ook de wens voor een extra aansluiting van PACS(2) applicatie of VNA, neem dan contact met ons op.
Contractverlenging Radboudumc en Amsterdam UMC
Wij zijn blij om te vermelden dat Radboudumc en het Amsterdam UMC de succesvolle samenwerking de komende jaren met ons voortzetten. Afgelopen maanden is hard gewerkt aan de contractverlengingen met beide organisaties, waarmee de basis is gelegd voor intensiever en breder gebruik van onze technologie de komende jaren.
Zowel Radboudumc in de regio Nijmegen als Amsterdam UMC in de hoofdstedelijke regio, vervullen een spilfunctie in hun zorgnetwerken. De XDS-infrastructuur vormt de digitale snelweg die deze netwerken ondersteunt. Dankzij deze technologie kunnen specialisten in verschillende ziekenhuizen met dezelfde, up-to-date informatie werken, wat dubbel onderzoek voorkomt en de patiëntveiligheid ten goede komt.
Wij danken beide organisaties voor het vertrouwen en kijken uit naar de verdere samenwerking!
IHE Connectathon Wenen
Team Founda is na een eerdere succesvolle IHE connectathon in de VS dit keer afgereisd naar Wenen voor de Europese editie. Het doel van een IHE Connectathon is om de interoperabiliteit tussen zorginformatiesystemen van verschillende leveranciers te testen en valideren op basis van de IHE-profielen. Concreet houdt dit in:
- Systemen koppelen en samenwerken: Tijdens een connectathon testen deelnemers of hun systemen correct kunnen communiceren met andere systemen, volgens gestandaardiseerde IHE-profielen (zoals XDS, PIX, PDQ, etc.).
- Technische compatibiliteit aantonen: Het is een soort "praktijkproef" om te laten zien dat je systeem écht werkt zoals gespecificeerd, niet alleen op papier.
- Fouten opsporen en oplossen: Deelnemers ontdekken tijdens de tests vaak knelpunten in hun implementatie en kunnen die ter plekke corrigeren.
- Voorbereiding op certificering of productie: Een succesvol resultaat op een connectathon is vaak een vereiste voor deelname aan vervolgtests of voor inzet in een productieomgeving.
De officiële resultaten van de bijeenkomst in Wenen worden binnenkort verwerkt door de IHE organisatie en gepubliceerd op de volgende site. De resultaten behaald in de VS zijn hier al te vinden: Resultaten Connectathon
Sfeerimpressie team Founda bij de connectathon in Wenen
Web Access to DICOM Objects
WADO is de afkorting van Web Access to DICOM Objects. De eerste versie werd rond 2003 geïntroduceerd in de DICOM(Web)-standaard, toen de eerste webgebaseerde DICOM-viewers hun weg vonden naar de zorgmarkt. De eerste WADO (uri)-versie definieert hoe het hypertext transfer protocol (http) gebruikt kan worden om DICOM-beelden op te halen via een GET-operatie. Hierbij worden verschillende queryparameters aangeboden waarmee client applicaties zowel gerenderde als 'ruwe' DICOM-objecten kunnen opvragen.
Sinds de introductie is WADO geëvolueerd via een 'Web Services'-versie naar een restful-versie die rond 2010 werd geïntroduceerd. Omdat restful-API's snel populair werden, raakte WADO−ws verouderd, waardoor de industrie overbleef met de oorspronkelijke WADO−uri- en de nieuwste WADO−rs-versies.
WADO−rs is een van de vijf restful-services die zijn geïntroduceerd met de DICOMWeb-standaard, ook wel bekend als DICOM Part 18. Terwijl WADO−rs de functionaliteit van een DICOM C−GET-service evenaart, doen de andere services dat voor andere DICOM DIMSE-services die zijn gedefinieerd in DICOM Part 4.
WADO−uri werd snel opgepikt door de IHE-gemeenschap als een eenvoudig te implementeren transactie (ook wel RAD−55 genoemd). Dit stelt een "beelddocument-consumer", zoals een universele viewer, in staat om diagnostische beelden op te halen bij een "beelddocument-bron", zoals een PACS. RAD−55 is terug te vinden in verschillende IHE-profielen, waaronder XDS−I, waar het wordt geïntroduceerd naast een traditionele DICOM query/retrieve en de "WADO−ws-achtige" RAD−69-transacties.
WADO−rs breidt de use-cases uit die door WADO−uri worden gedekt. Deze uitbreidingen voorzien onder andere in het ophalen van DICOM-metadata, bulkdata, pixeldata, gerenderde MPR, etc. Bovendien geeft het een client meer controle over hoe data wordt geretourneerd door een reeks HTTP accept-header-velden te definiëren.
Het Founda Health-platform biedt ondersteuning voor WADO−uri (RAD−55) sinds de introductie ervan binnen het XDS−I-profiel. Er is echter één grote beperking aan WADO−uri. Het kan niet worden gebruikt in een community-overschrijdende uitwisseling die is gebaseerd op het XCA−I-profiel, aangezien dit profiel alleen een variant van WADO−ws gebruikt, de zogenaamde RAD−75-transactie. Helaas profileert RAD−75 alleen het gebruik van WADO−ws voor het ophalen van volledige DICOM-data van diagnostische kwaliteit uit een externe community. Het XCA−I-profiel gaat er namelijk van uit dat alleen systemen zoals een PACS de moeite zouden nemen om externe beelden op te halen.
Tijdens meerdere implementaties realiseerden we ons de noodzaak om ook het ophalen van gerenderde beelden mogelijk te maken, zoals WADO−uri toestaat. Dit is voornamelijk omdat gebruikers graag een "sneak preview" willen zien van wat ze gaan ophalen voordat ze dit doen, aangezien het daadwerkelijke ophalen tijd kan kosten, afhankelijk van de grootte van het onderzoek en de beschikbare netwerkbandbreedte. Daarom hebben we een beetje vrijheid genomen en RAD−75 uitgebreid (in overeenstemming met de WADO−ws standaard) om ook gerenderde beelden op te halen. Deze uitbreiding is overeengekomen met een aantal Nederlandse leveranciers en beschreven in een technische afspraak.
Hoe goed deze uitbreiding ook werkt, het voelde alsof we niet trouw waren aan onze eigen missie om op standaarden gebaseerde interoperabiliteit te bieden, aangezien niet verwacht kan worden dat andere leveranciers hetzelfde doen. Daarom hebben we besloten om onze XCA−I gateway service uit te breiden en WADO−rs te gebruiken voor het ophalen van zowel gerenderde als 'ruwe' DICOM-beelden, in lijn met het concept profiel XC−WADO.
Hoe werkt het?
De verschillende community-overschrijdende toegangsmogelijkheden van ons platform, wordt een IHE XCA(−I)-gateway vertegenwoordigd door twee actoren: de initiërende gateway en de reagerende gateway. Terwijl het XCA-profiel ITI−38 (cross-community query) en ITI−39 (cross-community retrieve) introduceert, voegt het XCA−I profiel hier RAD−75 aan toe, specifiek voor het ophalen van beelden tussen communities. Vanaf release 2025-1 van het Founda Health-platform is een nieuwe transactie toegevoegd waarnaar wordt verwezen door het conceptprofiel XC−WADO (cross-community WADO).
Andrei Leontiev is de auteur van dit nieuwe IHE Radiology-profiel dat definieert hoe een op WADO−rs gebaseerde transactie gebruikt kan worden om (DICOM-)beelden op te halen uit een externe community. Deze transactie wordt aangeduid als RAD−160 en profileert het gebruik van WADO−rs voor het ophalen van zowel gerenderde als ruwe DICOM-beelden. XC−WADO maakt gebruik van dezelfde homeCommunityID- en retrieveLocationUID-concepten als het oorspronkelijke XCA-profiel om een beeldophaalverzoek te federeren van een Imaging Document Consumer (bijv. een PACS-werkstation of een lichtgewicht (web)applicatie) naar een of meer externe communities waar de Imaging Document Source (bijv. PACS of VNA) zich bevindt.
Aangezien het XC−WADO-profiel zich nog in een vroege fase bevindt en nog een openbare commentaarronde en connectathon-testen zal doorlopen, is het te verwachten dat er in de loop van de tijd wijzigingen en/of verbeteringen zullen worden aangebracht.
Er lijkt enige verwarring te bestaan dat hetzelfde kan worden bereikt met het IHE WIA-profiel, aangezien dit profiel ook definieert hoe WADO−rs (ook bekend als RAD−107) moet worden gebruikt. IHE WIA profileert het gebruik van WADO−rs voor intra-enterprise use-cases waarbij zowel de beelddocument-bron als de consumer zich binnen dezelfde onderneming of community bevinden. Hoewel RAD−107 en RAD−160 op het eerste gezicht sterk op elkaar lijken, volstaat de eerste dus niet voor een use-case waarbij de consumer en de bron zich in verschillende communities bevinden.
Samenvatting
WADO−rs biedt een moderne, restful-benadering voor het ophalen van beelden van een beeldbron zoals een PACS- of VNA-systeem. Het nieuwe (concept) XC−WADO-profiel van het IHE Radiology-domein profileert het gebruik van WADO−rs voor het ophalen van beelden tussen communities. Als zodanig introduceert XC−WADO een technologische vernieuwing voor de bestaande RAD−75-transactie die is gedefinieerd in het IHE XCA−I-profiel. Founda Health blijft voorop lopen in het adopteren van nieuwe profielen en heeft een eerste versie van de nieuwe RAD−160 transactie geïmplementeerd in haar gateway-service.