Koppelen van DVDExit aan lokaal XDS netwerk

[Laurens de Groot]

Vraag
In hoeverre bestaat de wens tot koppeling van DVDExit aan XDS (op welke specifieke manier dan ook) ook onder andere deelnemende ziekenhuizen?

Toelichting
We zijn in Nijmegen stiekem best trots op de wijze waarop wij al sinds langere tijd nu onze archiveer workflow hebben ingericht. Waar voorheen de afdeling Radiologie een cruciale rol speelde bij het verzend- en ontvangstproces, was onze inschatting en ervaring dat met de stijgende behoefte aan digitale uitwisseling, dit niet houdbaar zou zijn. Vijf jaar geleden ontvingen wij als academisch huis al meer dan 50.000 DVD's per jaar en dat zou alleen maar stijgen.

We hebben dat proces dus zo veel mogelijk gedecentraliseerd. Afdelingen / specialisten hebben zelf toegang tot het XDS netwerk en kunnen geïntegreerd via hun EPD (Epic) zoeken naar informatie buiten de muren van ons ziekenhuis. Hebben ze die gevonden, dan is die meteen en snel te raadplegen, maar is er ook een mogelijkheid om de data binnen te halen. Dat binnenhalen gebeurt allemaal door de gebruiker zelf, waarbij tevens een stukje data sanitizing plaatsvindt - alle geimporteerde studies worden conform een vastgestelde LOINC codetabel gecodeerd en als zodanig in alle systemen opgeslagen. Verloopt allemaal automatisch met bijbehorende orders in het EPD zonder handmatige tussenkomst van een gebruiker.

Dit hele proces kan dus dag en nacht door de gebruiker zelf worden ingezet, zonder benodigde hulp van een afdeling Radiologie. Onze gebruikers zweren bij de enorme versnelling die dit bracht in doorlooptijd en het maakt toepassing van ons XDS netwerk buiten kantoortijden haalbaar. Inmiddels heeft ook Philips 'het licht gezien' en bieden ze deze mogelijkheid commercieel aan, aan andere klanten (overigens zonder vermelding van credits - ouch).

Onze uitdaging
Nu willen wij, eenmaal gewend aan deze automatische werkwijze, ook graag dat externe onderzoeken via DVDExit op deze zelfde wijze kunnen landen op ons interne XDS netwerk. We merken immers dat gebruikers klagen over de traagheid waarmee beelden beschikbaar zijn. Dat vindt zijn oorzaak deels in de performance van het Alphatron netwerk, maar zeker ook deels omdat er nu opeens weer sprake is van een handmatig verwerkingsproces bij het ontvangen van studies. Wij koppelen DVDExit dus aan onze interoperability-broker (XDS) en niet rechtstreeks aan ons PACS. Omdat dat niet past in onze RIS-driven workflow maar ook omdat we straks met zaken als BgZ denken dat we niet goed uitkomen als dat in het PACS landt (plus: we die vervuiling tegen willen gaan).

Philips houdt deze boot echter nogal af en ziet op tegen de ontwikkeling die er voor nodig is. Verwijst daarbij onder andere naar een of andere uitspraak vanuit Twiin dat een 'fase-2 integratie van DVDExit' niet ondersteund zou worden. Zonder in een welles/nietes te willen landen, vraag ik me af in hoeverre de wens tot koppeling aan XDS (op welke specifieke manier dan ook) ook onder andere deelnemende ziekenhuizen leeft.

 

[Arina (Twiin/VZVZ)]

@KoenL kunnen wij deze vraag adresseren bij project DVDexit @OnnoGabel of project Knoop. @Milo ?
Ik zal kijken hoe we deze vraag via de DVDexit gebruikersgroep uit kunnen zetten. Gezien de gevoeligheid niet via LinkedIn ;-)

 

[OnnoGabel]

Op dit moment krijgt het projectteam DVDexit geen vragen of signalen binnen van andere instellingen om DVDexit te koppelen aan een XDS-omgeving. Technisch is het goed haalbaar om vanuit een push-omgeving bestanden 'neer te zetten' op een pull-omgeving. Andersom is niet haalbaar. Bij deze brug zijn de volgende aandachtspunten:

1. BSN: in push-netwerk DVDexit is de technische aanwezigheid van de BSN geen vereiste. In de pull-netwerken is de technische aanwezigheid van de BSN wel een vereiste; althans in de bestaande bekende netwerken. Mogelijke oplossingen is om het verkeer zonder BSN te 'scheiden'. Uitdaging bij het scheiden is of je redelijkerwijs mag verwachten dat verzenden 'op de hoogte is' van de aanwezigheid de BSN in DICOM en/of de bestemming de technische aanwezigheid van de BSN vereist. Als deze niet op de hoogte is, dient het ontvangende netwerk een oplossing te bieden voor die use cases waar BSN ontbreekt; een aftakking naar een 'uitvalbakje' waar wie wanneer naar kijkt?
2. Expliciete toestemming: in het ontvangende pull-netwerk wordt gewerkt met expliciete toestemmingen. Het ontvangende netwerk zal op basis van de verzonden informatie een expliciete toestemming moeten maken; deze toestemming zal specifiek moeten zijn opdat alleen de instelling voor wie het onderzoek is bestemd toegang heeft tot dit onderzoek.

Alternatief is dat het XDS-platform ook functionaliteit gaat bevatten om deel te nemen aan het push-netwerk. En niet op infra-niveau, maar op applicatie-niveau de gebruikers een oplossing gaat bieden.

 

[Laurens de Groot]

Ter aanvulling, inmiddels hebben wij deze koppeling bij Philips in opdracht gegeven. Hopelijk dus binnenkort meer info over hoe dit kan bijdragen aan een vloeiende workflow, ook voor het Twiin-portaal wanneer er niet voor gekozen is om dat in het PACS in te bouwen.

 

[Gilbert Bod]

Een tijdje geleden zijn diverse UMC's bij elkaar geweest en hebben het hier over gehad. Er is zeker grote behoefte om DVD exit te koppelen aan het XDS platform, met name om de redenen die Laurens benoemd (we willen een bruikbare oplossing voor onze eindgebruikers). Philips geeft echter aan dat het een te complexe en op maat gemaakte koppeling is, die voorgesteld is in Nijmegen. Misschien zouden we toch gezamenlijk nogmaals met Philips het gesprek moeten voeren.

 

[Hendrik Nijman]

Ook bij ons (Sint Maartenskliniek) is die wens er zeker. Ook hier is de verwerkingstroom van decentraal naar centraal (lee bij radiologie) verschoven.
Ik zie nog wel een uitdaging in wat er dan in het PACS gaat landen. We lopen toch nog steeds tegen een grote hoeveelheid irrelevante onderzoeken aan die via Twiin-portaal gesuurd worden.

 

[Cees Swinkels]

Hallo Laurens. In onze regio hebben we drie ziekenhuizen volledig ontsloten op XDS voor zowel PACS1 als PACS2. Ook Een vierde ziekenhuis met alleen radiologie en een diagnostisch centrum voor het opvragen (DvU). Daarnaast gebruiken we voor al de andere landelijke uitwisseling TWIIN. Wat ik van het TWIIN afspraken stelsel begrijp is dat het straks helemaal uit beschikbaar stellen (XDS) zal gaan bestaan via knooppunten.
Kun jij eens toelichten hoe je koppeling dan ziet tussen DVDExit (push) en XD? Wil je dan een XCA naar bij Alphatron waar ze een soort van centrale XDS repository hebben (en index)? . En ben je hiermee juist niet aan het zorgen voor een enorme beeldredundantie? XDS is immers beschikbaar stellen en kijken en nog niet direct downloaden.
Met andere woorden ben ik benieuwd naar het ontwerp.,

 

[Laurens de Groot]

Hi Cees,

In algemeenheid valt er een goede discussie te houden over de wens en noodzaak tot beide varianten van gegevensuitwisseling (vooraf beschikbaarstellen en via pull overhalen / XDS - danwel ad hoc in de brievenbus van de ontvanger duwen / Twiin-XDM). Ik denk dat zeker voor nu maar beargumenteerbaar ook in de toekomst beide varianten naast elkaar moeten bestaan. Er zijn veel voordelen te benoemen aan de manier waarop via XDS wordt uitgewisseld en zeker voor de hoog-volume uitwisselingen blijft dat de voorkeurs optie. Overigens wordt ook bij XDS/pull meestal de informatie overgenomen in het eigen ontvangende systeem. De bedoeling is weliswaar dat dat steeds selectiever gebeurt maar een sterke vorm van redundantie zal er voorlopig wel blijven. Hoewel strikt juridisch niet noodzakelijk (een beoordeling mag best op informatie die niet in het eigen systeem is opgeslagen) begrijp ik de wens van de daarvoor persoonlijk verantwoordelijke zorgverlener om toch altijd te kunnen beschikken over die informatie, bijvoorbeeld wanneer die later nog eens bekeken moet worden om wat voor reden dan ook. Je kan natuurlijk beargumenteren dat dan opnieuw de informatie remote opgevraagd kan worden, maar dan maak je je erg afhankelijk van de beschikbaarheid bij een externe partij, buiten je eigen invloedsfeer als ziekenhuis (plus een flink aantal technische afhankelijkheden). Een keuze die de meeste huizen nog niet durven te maken.

Replicatie van data zal er voorlopig dus wel blijven denk ik, totdat de garanties voldoende zijn dat centraal beschikbare of vanuit andere bron beschikbaar gestelde informatie met voldoende betrouwbaarheid ook beschikbaar blijft.

Wat de koppeling tussen Twiin en XDS bij ons met name sterk zal verbeteren is ons interne proces. We hebben met ons on-premise XDS platform een sterke koppeling gebouwd tussen het patform (Forcare) en ons EPD (Epic) en PACS (Agfa). Gevolg is dat we in staat zijn om eenvoudig de gebruiker zelf te laten archiveren maar daarbij standaardisatie van data (in LOINC) en closed-order-loop te respecteren. De zorgverlener moet dus wel zelf besluiten welke data hij overneemt dus je minimaliseert de onnodige import zoals @Hendrik Nijman beschrijft (en zoals dat met 'oude' DVD import altijd ging: importeer de hele DVD maar). Die flow is inmiddels al jaren in gebruik bij ons en onze gebruikers en we zouden ook de data die vanuit Twiin binnen komt, op die manier op dezelfde wijze aan gebruikers ter beschikking willen stellen. Eén uniforme workflow dus ongeacht of data via XDS/Knoop of XDM/Twiin binnen komt.

Let wel, dat is voor nu onze insteek om op korte termijn de beste oplossing voor gebruikers te realiseren. Ook wij moeten vooruit kijken en een situatie waarbij integratie van een tijdlijn in Pacs of EPD zichtbaar is, heeft natuurlijk de voorkeur. Maar dat is nog best ver weg dus eerst maar eens doen wat wel te realiseren is. Philips is overigens op dit moment de betreffende integratie met Alphatron aan het bouwen bij ons.

Misschien dat @Erik Janssen nog wat meer kan delen over de technische achtergrond van de koppeling, als daar behoefte aan is.

 

[Cees Swinkels]

Hallo Laurens,
Dank voor je uitgebreide reactie. Nog als vraag:
Waaruit maak je op dat "Hoewel strikt juridisch niet noodzakelijk ..."? Deze discussie hoor ik ook wel eens en kon niet de bron achterhalen.
En over de koppeling ben ik inderdaad geinteresseerd. Met name hoe je een koppeling kan maken tussen deze systemen die toch geheel anders van aard zijn en welke impact dit dan zou hebben op de werkprocessen (push vs pull).

 

[Erik Janssen]

Hoi allen,

Hierbij een korte toelichting over de aanstaande koppeling (bouw en ervaringen verwacht in tweede helft van 2022);

Belangrijk aspect van onze inrichting is dat we het Philips XDS product gebruiken voor verwerking van alle externe Radiologie en Cardiologie beelden. In Philips XDS zijn voor al onze gebruikers beeldstudies te zien van XDS gekoppelde ziekenhuizen + externe beelden die handmatig geïmporteerd zijn (Zip-bestanden en DVDs). Er is één archiveerscherm waarmee externe beeldstudies door gebruikers eenvoudig opgeslagen kunnen worden in de Radboud systemen, met automatische ordering in EPD + verificatie in PACS.

Om die reden hebben we het ontvangstproces van DVDexit niet gekoppeld aan ons PACS omdat dit zou betekenen dat we voor onze werkprocessen weer zouden moeten terugvallen op PACS-unverified en specifieke (Radiologie) beheerders die deze handmatig moeten verwerken. Daarnaast zijn onze Radiologie en Cardiologie PACSen gescheiden, dus een koppeling met enkel Radiologie PACS is ongewenst als we ook ooit Cardiologie studies willen gaan verwerken.

Ons huidige DVDexit ontvangstproces is voor gebruikers momenteel als volgt;
1. Notificatiemail --> 2. Downloaden DVDexit studie in ZIP --> 3. Importeren ZIP in Philips XDS --> 4. Archiveren studie met Philips XDS archiveerscherm

Met een DVDexit-PhilipsXDS koppeling kunnen stappen 2+3 voor studies met BSN weggenomen kunnen worden.
Wanneer een studie BSN bevat in de juiste DICOM velden (PatientID + IssuerOfPatientID) dan stuurt de lokale Alphatron gateway server deze door naar lokale Philips XDS server (DICOM Store). Daar zullen de beeldstudies in de context van de patiënt verschijnen.
Wanneer de studie geen BSN in de juiste velden bevat, of de patiënt in onze organisatie nog niet met BSN is geregistreerd, zijn er nog aanvullende handmatige acties nodig.

Begrijp dat Philips dit als een maatwerk oplossing ziet en terughoudend is met het uitdragen hiervan, omdat deze constructie uitgaat van het archiveerscherm en lokale servers waarop de beelden ontvangen kunnen worden. Beiden zitten niet in de standaard/basis configuratie die Philips aanbiedt en is afhankelijk van de architectuuropzet icm XDSCloud.

Groet,
Erik

 

[Laurens de Groot]

Waaruit maak je op dat "Hoewel strikt juridisch niet noodzakelijk ..."? Deze discussie hoor ik ook wel eens en kon niet de bron achterhalen.

Er is zover ik weet vanuit WGBO dossierplicht dus alle onderdelen waarop een diagnose of behandelplan gebaseerd wordt dienen in dossiervoering te zijn opgenomen (vrije vertaling), maar ik heb nergens kunnen vinden of lezen dat er ook eisen worden gesteld aan de fysieke locatie van (delen van) dat dossier. Dus een zorgaanbieder kan er voor kiezen om een deel van dat dossier bij derden onder te brengen zolang er maar aan de eisen wordt voldaan die daaraan gesteld worden. Het is denk ik goed voor te stellen dat met name dat laatste punt lastig verifieerbaar is en daarmee een goed argument om niet voor die constructie te kiezen en (dus) data toch te repliceren.

Maar eerlijk is eerlijk: 1) het is inmiddels lang geleden dat ik die WGBO teksten op een goede zomermiddag tot me nam, en 2) ik ben geen jurist. Tegelijkertijd denk ik dat veel implementaties in Nederland gebaseerd zijn op dit soort 'vrije interpretaties'

 

[Cees Swinkels]

Hoi allen,

Hierbij een korte toelichting over de aanstaande koppeling (bouw en ervaringen verwacht in tweede helft van 2022);

Belangrijk aspect van onze inrichting is dat we het Philips XDS product gebruiken voor verwerking van alle externe Radiologie en Cardiologie beelden. In Philips XDS zijn voor al onze gebruikers beeldstudies te zien van XDS gekoppelde ziekenhuizen + externe beelden die handmatig geïmporteerd zijn (Zip-bestanden en DVDs). Er is één archiveerscherm waarmee externe beeldstudies door gebruikers eenvoudig opgeslagen kunnen worden in de Radboud systemen, met automatische ordering in EPD + verificatie in PACS.

Om die reden hebben we het ontvangstproces van DVDexit niet gekoppeld aan ons PACS omdat dit zou betekenen dat we voor onze werkprocessen weer zouden moeten terugvallen op PACS-unverified en specifieke (Radiologie) beheerders die deze handmatig moeten verwerken. Daarnaast zijn onze Radiologie en Cardiologie PACSen gescheiden, dus een koppeling met enkel Radiologie PACS is ongewenst als we ook ooit Cardiologie studies willen gaan verwerken.

Ons huidige DVDexit ontvangstproces is voor gebruikers momenteel als volgt;
1. Notificatiemail --> 2. Downloaden DVDexit studie in ZIP --> 3. Importeren ZIP in Philips XDS --> 4. Archiveren studie met Philips XDS archiveerscherm

Met een DVDexit-PhilipsXDS koppeling kunnen stappen 2+3 voor studies met BSN weggenomen kunnen worden.
Wanneer een studie BSN bevat in de juiste DICOM velden (PatientID + IssuerOfPatientID) dan stuurt de lokale Alphatron gateway server deze door naar lokale Philips XDS server (DICOM Store). Daar zullen de beeldstudies in de context van de patiënt verschijnen.
Wanneer de studie geen BSN in de juiste velden bevat, of de patiënt in onze organisatie nog niet met BSN is geregistreerd, zijn er nog aanvullende handmatige acties nodig.

Begrijp dat Philips dit als een maatwerk oplossing ziet en terughoudend is met het uitdragen hiervan, omdat deze constructie uitgaat van het archiveerscherm en lokale servers waarop de beelden ontvangen kunnen worden. Beiden zitten niet in de standaard/basis configuratie die Philips aanbiedt en is afhankelijk van de architectuuropzet icm XDSCloud.

Groet,
Erik

Dank Erik
Even kijk of ik je goed begrijp: dus als een externe instelling dan met DVDExit beelden naar jullie wil sturen stuurt de Alphatron Gateway bij jullie ziekenhuis het beeld door naar jullie XDS repository en wordt deze daarmee opgenomen (inclusief aanmaken van een KOS object).. Daarmee wordt het zichtbaar en kun je dus zelf archiveren conform de methode die jullie hebben (wij hebben overigens ook Philips).
Heb je ook een suggestie voor terug? Dus als je iets terug wil sturen via XDS naar DVDExit? Dat lijkt me dan niet mogelijk toch omdat dat versturen als functie ingebouwd zit in de Alphatron oplossing en niet zondermeer via XDS te doen is?

 

[Cees Swinkels]

Er is zover ik weet vanuit WGBO dossierplicht dus alle onderdelen waarop een diagnose of behandelplan gebaseerd wordt dienen in dossiervoering te zijn opgenomen (vrije vertaling), maar ik heb nergens kunnen vinden of lezen dat er ook eisen worden gesteld aan de fysieke locatie van (delen van) dat dossier. Dus een zorgaanbieder kan er voor kiezen om een deel van dat dossier bij derden onder te brengen zolang er maar aan de eisen wordt voldaan die daaraan gesteld worden. Het is denk ik goed voor te stellen dat met name dat laatste punt lastig verifieerbaar is en daarmee een goed argument om niet voor die constructie te kiezen en (dus) data toch te repliceren.

Maar eerlijk is eerlijk: 1) het is inmiddels lang geleden dat ik die WGBO teksten op een goede zomermiddag tot me nam, en 2) ik ben geen jurist. Tegelijkertijd denk ik dat veel implementaties in Nederland gebaseerd zijn op dit soort 'vrije interpretaties'

Dank Laurens,
Ik ben zelf een groot voorstander van vrije interpretaties dus kan me daarin vinden maar ben toch wel bang dat het juridisch lastig is. Een instelling A die beelden publiceert en door een specialist in instelling B gebruikt worden voor diagnostiek kan zomaar eens besluiten zijn publicatie stop te zetten (instelling A). Dan hang je al. Ik denk dat de WBGO hier zich nog maar eens over moet buigen. En daarmee vind ik eigenlijk wel dat hier ook een taak ligt van TWIIN om hier iets mee te doen. Beschikbaar stellen van beeld en verslag als duurzame oplossing (zeker als het gaat om een tijdslijn) zou dit moeten tackelen.

 

[Erik Janssen]

Dank Erik
Even kijk of ik je goed begrijp: dus als een externe instelling dan met DVDExit beelden naar jullie wil sturen stuurt de Alphatron Gateway bij jullie ziekenhuis het beeld door naar jullie XDS repository en wordt deze daarmee opgenomen (inclusief aanmaken van een KOS object).. Daarmee wordt het zichtbaar en kun je dus zelf archiveren conform de methode die jullie hebben (wij hebben overigens ook Philips).

Dit klopt.

Nog een kleine aanvulling; de externe beelden worden tijdelijk in de lokale XDS repository bewaard in een separate "Instelling" getiteld "Radboudumc-Imageupload" (2 maanden oid). Daarna weer automatisch opgeschoond. Zijn niet zichtbaar voor gekoppelde ziekenhuizen. Dat gaat op de achtergrond inderdaad technisch gepaard met een registratie in ForIndex en KOS objecten omdat dit de bouwstenen in de XDS applicatie zijn.

Maar is dus wel wat anders dan beeldstudies die wij in Radboud maken en aanbieden aan gekoppelde ziekenhuizen ("Instelling" = "Radboudumc"). Die blijven uiteraard gewoon staan.

Heb je ook een suggestie voor terug? Dus als je iets terug wil sturen via XDS naar DVDExit? Dat lijkt me dan niet mogelijk toch omdat dat versturen als functie ingebouwd zit in de Alphatron oplossing en niet zondermeer via XDS te doen is?

De koppeling waar we mee bezig zijn gaat alleen over het ontvangstproces, niet over het verzendproces.
Momenteel sturen wij beelden naar DVDExit ziekenhuizen via ons Agfa PACS systeem (middels integratie). Dit wordt door dezelfde groep mensen gedaan die voorheen de DVDs brandden. Koppeling met Philips XDS is ooit overwogen maar vanwege technische complexiteit en afhankelijkheden kwam dit niet van de grond. Als we in de toekomst meer mensen deze handeling willen laten kunnen uitvoeren, en ook voor andere beelden dan Radiologie, dan is wellicht integratie met Epic (verzendknop in clientapplicatie) en/of VNA (backend opslag van alle beelddata) mogelijk. Maar dan zullen we weer in gesprek moeten met Alphatron voor een aangepast design.