Evaluatie pilot eradiologie. Hans Mekenkamp. Projectleider. Versie: 1.0. Datum:

Dit document is door EZDA gerealiseerd in samenwerking met de deelnemende ziekenhuizen in de pilot “digitale beelduitwisseling eRadiologie in Amsterdam”. Nictiz heeft deze pilot medegefinancierd. Omdat dit document ontstaan is tijdens de uitvoering van de pilot, kan het voorkomen dat het document specifieke definities gebruikt die van toepassing zijn voor de Amsterdamse situatie. Dit is bewust in deze hoedanigheid gelaten om de leesbaarheid te vergroten. Dit document is een voorbeeld van kennisdeling. We hopen hiermee een bijdrage te leveren aan het stimuleren van de ontwikkelingen voor digitale beeld,- en verslag uitwisseling.

Evaluatie pilot eRadiologie Hans Mekenkamp Projectleider

Versie: 1.0 Datum: 15-03-2011

Elektronisch Zorg Dossier Amsterdam, 2011

DOEL VAN DIT DOCUMENT ..................................................................................................................... 3 1

MANAGEMENT SAMENVATTING .................................................................................................... 4

2

HISTORIE PILOT ................................................................................................................................. 5

2.1 KEUZE EN OVERWEGINGEN VOOR DE ZIEKENHUIZEN........................................................................... 5 DEELNEMENDE PARTIJEN IN PILOT ................................................................................................................ 6 3

DE IHE XDS OPLOSSING .................................................................................................................... 7

3.1 3.2 3.3 3.4 3.5 3.5.1 3.6 3.6.1 3.6.2

BESCHRIJVING VAN DE IHE XDS INFRASTRUCTUUR ........................................................................... 7 OPSCHALING KLINISCHE DOMEINEN .................................................................................................... 7 IHE PROFIELEN.................................................................................................................................... 8 IHE CONFORMANCE LEVERANCIERS................................................................................................... 10 BEVINDINGEN XDS-INFRASTRUCTUUR ............................................................................................. 11 IHE CONFORMANCE TESTEN LOKALE XDS COMPONENTEN ............................................................................. 11 IHE CONFORMANCE IN NEDERLAND .................................................................................................. 11 LEVERANCIERS CENTRALE COMPONENT IN DE REGIO ........................................................................................ 12 RFI POTENTIELE LEVERANCIERS CENTRALE REGISTRY...................................................................................... 12

4.1 4.2 4.3

AANPAK TESTEN ................................................................................................................................ 13 FACILITAIRE ONDERSTEUNING PROJECT............................................................................................ 14 AANDACHTSPUNTEN BIJ TESTEN ....................................................................................................... 14

4

5

PROJECTORGANISATIE ................................................................................................................... 13

PROCESAANPASSING/WORKFLOW ............................................................................................. 16

5.1 USE CASES .......................................................................................................................................... 16 5.2 VOORBEELD DOORVERWIJZEN............................................................................................................. 17 5.2.1 PROCESSCHEMA ............................................................................................................................................................. 17 5.2.2 EVENT .............................................................................................................................................................................. 18 5.2.3 STAPPEN .......................................................................................................................................................................... 18 5.2.4 RESULTAAT ..................................................................................................................................................................... 18 5.3 PRAKTIJK ERVARING .......................................................................................................................... 19 6 6.1 6.2 6.3 6.4 6.5 7

PRIVACY .............................................................................................................................................. 20 AANDACHTSPUNT GEDRAGSCODE ELEKTRONISCHE UITWISSELING EN CONVENANT ........................ 20 GEDIFFERENTIEERD PRIVACYBELEID ................................................................................................ 20 UITGANSPUNTEN PATIENT CONSENT ................................................................................................. 21 IHE EN PRIVACY................................................................................................................................. 22 PRIVACY BIJ START PRODUCTIE......................................................................................................... 22 BUSINESS CASE EN MODEL ............................................................................................................ 23

7.1 BUSINESSMODEL ................................................................................................................................ 23 7.1.1 AANBOD MODEL............................................................................................................................................................ 23 7.1.2 VERDEELSLEUTEL ........................................................................................................................................................ 23 7.2 BUSINESSCASE.................................................................................................................................... 24 Versie 1.0.1

Pagina 2 van 36

8 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 9

TECHNISCHE INFRASTRUCTUUR ................................................................................................. 27 NETWERK .......................................................................................................................................... 27 AANDACHTPUNTEN CONFIGURATIE NETWERK .................................................................................. 27 UITGANGSPUNTEN ARCHITECTUUR BEVEILIGING ERADIOLOGIE....................................................... 28 AANPAK TECHNIEK BINNEN ZIEKENHUIS ........................................................................................... 28 ZIEKENHUIS INFRASTRUCTUUR VOOR ALLE BEELDEN ....................................................................... 29 AANSLUITDOCUMENT ........................................................................................................................ 30 REGIONALE INFRA .............................................................................................................................. 30 AANSLUITING LSP ............................................................................................................................. 31 TIPS OP EEN RIJ ................................................................................................................................ 34

9.1 9.2 9.3 9.4 9.5

STERKE PUNTEN PILOT ...................................................................................................................... 34 VERBETERPUNTEN............................................................................................................................. 34 VOORDEEL DEELNAME AAN PILOTS ................................................................................................... 34 WAT MOETEN WE NOG DOEN BINNEN DE REGIO VOOR GO LIVE?........................................................ 35 WAT MOETEN WE NOG DOEN BIJ NICTIZ/VWS? ............................................................................... 35

10

BIBLIOTHEEK ................................................................................................................................. 36

Doel van dit document In dit document staan de ervaringen die zijn opgedaan tijdens de pilot eRadiologie in Amsterdam. De verschillende disciplines geven op diverse onderwerpen advies. Het document is bedoeld voor mensen die aan de slag gaan met beeld- en documentuitwisseling tussen zorginstellingen.

EZDA EZDA Registry beelden i d AMC

Bovenij

OLVG

Auteur: ir. J.W. Mekenkamp, MedicalPHIT

Commentaren: J.Straatman, H. Barenbrug, H. Bonsen, W.Baller, H. Hutink P.H. Zwaal, J. Smeets (Fuji), E. Bijkerk (AGFA), RJ Besselink (E.Novation Versie 1.0.1

Pagina 3 van 36

1 Management samenvatting

Na jaren van voorbereiding heeft eind 2010 een technische test plaatsgevonden met beelduitwisseling tussen drie Amsterdamse ziekenhuizen.

De Stichting Elektronisch ZorgDossier Amsterdam (EZDA) heeft het project eRadiologie geleid in samenwerking met het OLVG, AMC, VU, NKi en Bovenij ziekenhuis. Nictiz heeft de pilot financieel gesteund en een aantal werkgroepen begeleid. De betrokkenheid en doorzettingsvermogen van de leveranciers (AGFA, Fuji, E.novation en Forcare) heeft er voor gezorgd dat in slechts 2 maanden tijd de Proof of Concept is aangetoond. Beelden en verslagen zijn verstuurd en opgehaald tussen de ziekenhuizen OLVG, AMC en Bovenij volgens de internationale standaarden zoals die zijn beschreven door IHE (Integrating the Healthcare Enterprise).

De standaard XDS-I staat voor Cross Enterprise Document Sharing for Imaging en wordt in meer of mindere mate door alle PACS leveranciers in Nederland ondersteund. Er zijn ook meerdere leveranciers die brokers leveren zodat in principe alle ziekenhuizen aan transmurale beelduitwisseling volgens de standaard kunnen deelnemen. Naast een technische proof of concept zijn er een aantal werkgroepen actief geweest. De belangrijkste conclusies staan hieronder. 1. Workflow: De belangrijkste radiologische workflows zijn beschreven, waaronder doorverwijzing, 2nd opinion, collegiaal consult en ad hoc opvragen.

2. Businesscase: De conclusie is dat voor EZDA het business model bestaat uit enerzijds wijze waarop een beeldendienst door EZDA ingekocht kan worden, namelijk als dienst (SAAS) en anderzijds hoe die door de deelnemende ziekenhuizen betaald gaat worden, namelijk op basis van de huidige EZDA verdeelsleutel. De businesscase is alleen positief voor een deelnemend ziekenhuis als een aantal strategisch belangrijke (klinische) cases direct baat hebben bij beelduitwisseling, bijvoorbeeld in het kader van strategische samenwerking tussen ziekenhuizen of het werken op meerdere locaties. Enkel en alleen kijkend naar de vervanging van de directe kosten gerelateerd aan CD’s is de businesscase negatief. Dit komt o.a. doordat veel CD’s van en naar andere dan EZDA ziekenhuizen komen en gaan. 3. Privacy: Na lang discussiëren is de conclusie dat voor zowel het aanmelden aan een registry (verwijsindex voor beelden) als het ophalen expliciete toestemming van de patiënt noodzakelijk is. Dit betekent dat niet alle radiologische onderzoeken automatisch aangemeld mogen worden. Met name de wijze waarop patiënt consent gevraagd en geregistreerd moet worden in de praktijk vergt nog nadere verdieping.

4. Architectuur: De regionale architectuur is uitgewerkt op basis van een aantal internationale profielen van IHE. Behalve het gebruik van het BSN en UZI-passen zijn er geen bijzonderheden. Tijdens de technische pilot bleek wel dat een aantal profielen nog niet door alle leveranciers ondersteund worden zoals BPPC (patiënt consent) en WADO (web toegang van beelden). Voor de landelijke opschaling is er een verkenning gedaan door Nictiz en IHE. Het samenvloeien van een XDS omgeving en het LSP vergt nog wel nadere verdieping.

2 Historie pilot In het kader van het landelijke programma eRadiologie van NICTIZ is in de regio Amsterdam een pilot uitgevoerd onder regie van EZDA. Na een haalbaarheidsstudie in 2007 is in 2008 gestart met een aantal werkgroepen en ziekenhuizen om een technische pilot te starten. De deelnemende ziekenhuizen waren bij de start het AMC, VU, NKI en OLVG. Tussen 2008 en 2011 is op verschillende wijze bijgedragen door de ziekenhuizen aan het voorbereiden van de echte pilot en zaken beschreven. Uiteindelijk hebben de testen in december 2010 en januari 2011 plaatsgevonden ism het AMC, OLVG en Bovenij. In de pilot in Amsterdam hebben we met name gekeken naar: 1. 2. 3. 4.

Workflow Businesscase Privacy Architectuur

In het landelijk programma wordt o.a. gewerkt aan de architectuur om XDS en LSP te koppelen en het uiteindelijke regime voor privacy en security bij het uitwisselen van radiologische beelden en verslagen tussen ziekenhuizen.

2.1 Keuze en overwegingen voor de ziekenhuizen

Tijdens de pilot hebben we gemerkt dat het voortraject in een ziekenhuis erg veel tijd kost. eRadiologie vormt veelal de eerste kennismaking met IHE XDS en wordt gezien als basis voor een breder in te zetten transmurale infrastructuur. Daarom zijn er mensen van verschillende disciplines betrokken bij voorwerk en besluitvorming. De onderwerpen die in kaart gebracht moeten worden zijn:

1. Welke afdelingen wisselen beelden uit en zijn geïnteresseerd. Wat is daarbij de belangrijkste workflow. 2. Wat is de Business case? 3. Hoe past XDS in de IT architectuur. Met name de keuze voor de repository, de koppelingen (PIX, PACS, RIS). 4. De logging (centraal of lokaal). En wat is het audit beleid? (wie bekijkt de logfiles en constateert misbruik?) 5. Het privacy vraagstuk. Wie mag wat zien. Wanneer moet de patiënt consent geven? 6. Wie neemt de beslissingen? 7. Keuze voor XDS componenten en daarbij de keuze voor leveranciers. In de pilotperiode bleek dat leveranciers in meer of mindere mate XDS functionaliteit hebben geïntegreerd in hun PACS. Veelal is een broker nodig om te kunnen voldoen aan de gewenste functionaliteit. Met name om het consent principe te ondersteunen. Bij ieder ziekenhuis speelde het een rol of de eigen PACS-leverancier de software zou kunnen leveren of dit via een XDS leverancier aangeschaft moest worden.

Met name het privacy vraagstuk en de kosten van de XDS infrastructuur hebben de implementatie tijdens de pilot vertraagd.

Versie 1.0.1

Pagina 5 van 36

Deelnemende partijen in pilot Ziekenhuizen die aan de pilot hebben meegewerkt zijn: Werkgroepen: OLVG, AMC, NKi

Technische pilot: OLVG, AMC, Bovenij

Leveranciers: AGFA, E.Novation, Forcare, Fuji Film Organisatie: EZDA, Nictiz

Versie 1.0.1

Pagina 6 van 36

3 De IHE XDS oplossing 3.1 Beschrijving van de IHE XDS infrastructuur Het radiologienetwerk is gebaseerd op basis van de “Cross-Enterprise Document Sharing” (XDS) concepten zoals die door de internationale “Integrating the Healthcare Enterprise (IHE)” organisatie zijn vastgelegd.

De RIS/PACS systemen zijn zodanig gestandaardiseerd dat er voldoende mogelijkheden zijn om dit radiologienetwerk te realiseren. De leveranciers zijn allemaal redelijk ver met de integratie van XDS compatibiliteit in hun producten, alhoewel die nog niet zijn geïmplementeerd op grote schaal. Vanuit technisch oogpunt bestaat een IHE XDS radiologienetwerk uit een centraal aangeboden verwijsindex (registry) en lokale opslagcomponenten (repositories).

In de verwijsindex worden de meta data van het radiologisch verslag en verwijzingen naar documenten, beelden en verslagen geregistreerd. De verslagen en beelden blijven lokaal in het ziekenhuis. Op dit moment zijn enkele RIS/PACS systemen al aangepast voor rechtstreekse XDS communicatie. Ook kan een lokale XDS broker geïmplementeerd worden om radiologische verslagen en (verwijzingen naar) beelden beschikbaar te stellen.

Zo’n lokale XDS broker kan worden ingezet zonder ingrijpende aanpassingen aan de bestaande RIS/PACS systemen.

Onderstaande figuur geeft een schematische weergave van de (XDS-I) infrastructuur. Afbeelding 1

3.2 Opschaling klinische domeinen De gerealiseerde infrastructuur kan breder worden ingezet dan voor het radiologie domein alleen. Voorbeelden hiervan zijn het gebruik voor het uitwisselen cardiologieinformatie, pathologie, laboratorium en medische samenvattingen. De basis hiervoor

Versie 1.0.1

Pagina 7 van 36

zijn de CDA documenten1. Ook zijn onderdelen van de infrastructuur geschikt voor hergebruik binnen de regio. 1e lijn zorgverleners kan optioneel toegang worden gegeven via een webbrowser. Koppeling naar andere beeldnetwerken wordt ondersteund, zodat aansluiting op het Landelijk Schakel Punt (LSP) gerealiseerd kan worden. Dit wordt verder uitgewerkt in het Nictiz eRadiologie programma. Hiervoor is de eerste verkenning reeds afgerond.

3.3 IHE profielen

Binnen eRadiologie beschrijven we de technische vereisten door te verwijzen naar internationale IHE profielen. Deze zijn na te lezen op wiki.ihe.net.

Benodigde IHE XDS profielen om de centrale infrastructuur te kunnen realiseren zijn:    

  

Consistent Time (CT) synchronisatie computer-klokken van alle systemen Audit Trail and Node Authentication (ATNA) beveiliging van communicatie tussen systemen logging van toegang tot patiëntengegevens Cross-enterprise Document Sharing (XDS.b) algemene infrastructuur voor informatie-delen XDS for Imaging (XDS-I) content profiel voor delen beeld en verslag Verslagen op basis van HL7 v3 CDA in PDF of plain text Beelden op basis van WADO Cross-Enterprise User Assertion (XUA en XUA++) overdragen gebruikersidentificatie (o.a. UZI nummer en rol) Basic Patient Privacy Consent (BPPC) vastleggen patiënttoestemming in gecodeerde documenten Patiënt Identifier Cross-Referencing (PIX) Verkrijgen van BSN nummer op basis van lokaal patiënt ID via een PIX query

Optioneel benodigd voor de opschaling naar meerdere regio’s en domeinen (denk aan MammoXL2).  

Cross-Community Access (XCA) koppelt XDS-gebaseerde regio’s gebruikt om regionale indexen te ontsluiten Document Metadata Subscription (DSUB) Realiseert de notificatie van wijzigingen aan patiënt record Wordt gebruikt om de verwijsindex up te daten.

Schematisch ziet een XDS-i infrastructuur er als volgt uit:

1 2

HL7 Clinical Document Architecture (CDA) MammoXL: landelijk XDS systeem voor uitwisseling digitale mammogrammen van het bevolkingsonderzoek naar borstkanker

Versie 1.0.1

Pagina 8 van 36

Afbeelding 2: basis XDS-I infrastructuur

In IHE profielen staat beschreven hoe systemen (Actoren) met elkaar gekoppeld kunnen worden en gegevens uit wisselen (Transacties). Deze transacties geven we weer middels pijlen met een cijfer. De actoren zijn gevisualiseerd als PC’s. Meerdere Actoren kunnen door eenzelfde applicatie ingevuld worden. Zo kan een PACS 3 bijvoorbeeld zowel Source als Repository en Consumer zijn. De XDS actoren zijn: Source (bronsysteem), Repository (waar de documenten opgeslagen zijn), registry (de verwijsindex) en de consumer (de client applicatie die de gegevens toont). XDS-I stelt PACS en RIS systemen in staat om een verzameling van XDS documenten met informatie te creëren en aan te melden in een algemeen XDS systeem. Het profiel definieert twee typen documenten: • •

Radiologisch verslag, in PDF (Portable Document Format – Adobe) of HL7 v3 CDA (Clinical Document Architecture) R2 formaat. Verwijzingen naar radiologische beelden via de DICOM 4 SOP Instance UIDs (unieke identifiers voor specifieke DICOM beelden), verzameld in een DICOM Key

3 PACS -> Picture Archiving and Communication System 4 DICOM -> Digital Imaging and Communications in Medicine

Versie 1.0.1

Pagina 9 van 36

Object Selection (KOS) structuur. Beelden worden beschikbaar gesteld op een andere manier (WADO 5) dan binnen een gewoon PACS (DICOM)

De actoren in een XDS omgeving zijn aan de kant van het ziekenhuis (zie afbeelding 2):

1. Document Source: dit is de bron van de informatie. Dit is bijvoorbeeld een RIS of PACS systeem 2. Document Repository: dit is de “logische” plek waar de op te vragen documenten en verwijzingen naar de DICOM beelden staan. Dit kan bijvoorbeeld het PACS zijn, maar ook een apart archief. NB: De repository kan zowel lokaal in het ziekenhuis als op een centrale locatie worden geplaatst. 3. Document consumer: dit is de client/applicatie waarmee een query op de registry wordt gedaan en de lijst met onderzoeken van een patiënt toont. Dit kan een aparte webapplicatie zijn, maar ook het PACS station van een radioloog of een EPD-client. 4. XDS-Broker: In het geval dat een systeem geen XDS ondersteunt maar wel DICOM (store SCU) of HL7 v2 of v3 dan kan een broker deze berichten vertalen en sturen naar de registry. Hierdoor wordt het mogelijk om onafhankelijk van de huidige ondersteuning van XDS door de RIS/PACS/EPD leverancier toch aan te sluiten op een XDS infrastructuur. (zie afbeelding 1)

De centrale actoren in een XDS omgeving zijn:

1. XDS registry: Dit is de verwijsindex waarin alle verwijzingen naar documenten en beelden staan die zijn aangemeld vanuit de aangesloten ziekenhuizen. 2. ATNA repository: Hierin staat de logging van alle transacties die binnen de XDS infrastructuur plaatsvinden. ATNA is een verplicht profiel en alle actoren ondersteunen dat. NB: er kan ook binnen het ziekenhuis een ATNA repository geplaatst worden om intern alles te kunnen loggen en de logfiles in te zien. 3. Patient identity feed: volgens het profiel is het mogelijk om alle patiënt gegevens binnen een affinity Domain (dit is bijvoorbeeld de regio, of binnen de regio een apart domein cardiologie) naar de registry te sturen. Hiermee vul je dan de registry met meta-data, zoals achternaam, BSN, geboorte datum, maar ook meisjesnaam, mansnaam etcetera. Dit is bijvoorbeeld de ADT-koppeling uit ieder aangesloten ziekenhuis. Omdat vanuit privacy oogpunt opname van patiëntgegevens in een registry niet mogelijk is zonder consent is dit in de pilot niet geïnstalleerd. Het gevolg is dat de registry gevuld wordt met de meta-data uit elke aanmelding. De rijkheid aan gegevens verschilt per ziekenhuis. Je kan dan ook alleen maar zoeken op een beperkt aantal velden.

3.4 IHE conformance leveranciers

IHE is een internationale organisatie van leveranciers en gebruikers. IHE werkt volgens een vast stramien van het definiëren van use-cases, het technisch beschrijven in een technical framework en het vervolgens testen op een zogeheten connectathon. 5 WADO -> Web Access to DICOM Objects

Versie 1.0.1

Pagina 10 van 36

Leveranciers kunnen daar hun software testen. Daarbij geven ze aan voor welke actoren en transacties binnen een profiel zij willen testen. Als je x maal positief hebt getest tegen 3 verschillende andere actoren/leveranciers dan mag je dat vermelden op je website in een IHE integration statement. Via www.IHE-nl.org, www.IHE.net of http://wiki.ihe.net kan je de resultaten van de verschillende internationale connectathons teruglezen. Als je de mogelijkheden van een bepaald systeem of alle systemen in het ziekenhuis wil onderzoeken kan dat door naar de websites van de leveranciers te gaan. Echter in veel gevallen wordt samengewerkt met software van verschillende firma’s. Daarom is het raadzaam om met betrokken leveranciers om de tafel te gaan zitten en uit te werken welke rol (actor) door welk systeem gespeeld gaat worden.

3.5 Bevindingen XDS-infrastructuur

3.5.1 IHE conformance testen lokale XDS componenten Tijdens het testen kwamen we er achter dat de(PACS) leveranciers van de lokale XDS infrastructuur op een aantal cruciale profielen nog niet alle transacties volledig ondersteunen. We moeten ons goed realiseren dat de meeste PACS leveranciers buiten Nederland ontwikkelen en dat zij conform de huidige markteisen (lees internationale standaarden) ontwikkelen. In Nederland wijken we op een aantal onderdelen af van de andere internationale projecten. Tevens blijkt dat de betrokken leveranciers nog maar recent XDS hebben ingebouwd, waardoor voor het eerst tegen praktijkproblemen werd aangelopen. De basis XDS-I transacties hebben we goed kunnen testen. Enige problemen vonden we in de ondersteuning van WADO (2 leveranciers) en HL7 v3 CDA voor verslagen (1 leverancier). Verder worden XUA en BPPC minimaal ondersteund en kunnen de PACS leveranciers de UZI-pas (nog) niet ondersteunen. Na de initiële testen hebben we gekeken naar een aantal andere aspecten. Deze behoeven voor productiegang nog de nodige aandacht:

1. Snelheid van het ophalen van beelden. Dit heeft met name te maken met DICOM transfer en het niet of niet handig gebruik maken van WADO, firewall configuratie en interne architectuur (tussen PACS en XDS brokers) 2. Het juist configureren van ALLE velden, zoals naam ziekenhuis, specialist, modaliteit, patiëntnaam, onderzoek, datum onderzoek versus datum aanmelden etcetera. 3. Lokale koppelingen, met name PIX (Patiënt Identity Cross reference), die de vertaling van lokaal patiënt ID naar BSN en vv verzorgt.

3.6 IHE conformance in Nederland

Tijdens de pilotperiode heeft EZDA tweemaal een RfI uitgestuurd naar leveranciers om te achterhalen of zij XDS componenten kunnen leveren en wat hun ervaringen daarmee zijn. Duidelijk is dat IHE XDS bij alle leveranciers in het radiologie domein gemeengoed is. Zij realiseren XDS compatibiliteit door eigen software ontwikkeling of doen dat in relatie met een XDS-component leverancier. ForCare heeft op dit moment een stevige positie door samenwerking met diverse leveranciers.

Versie 1.0.1

Pagina 11 van 36

3.6.1

Leveranciers centrale component in de regio

Er is voor de pilot een korte, snelle inventarisatie gemaakt langs mogelijke leveranciers van de centrale component in de regio, in de vorm van een dienst voor de duur van de pilot. Enovation/Forcare faciliteert de pilot t/m 1 april 2011. Criteria om te kwalificeren zijn in ieder geval:   

Heeft de leverancier meegedaan aan een Connectathon sinds 2008 en is gekwalificeerd voor alle basic profielen (XDS-Ib, ATNA, CT, BPPC, PIX en XUA) Doet de leverancier mee in 2011? Ervaring: is er al een daadwerkelijke implementatie? Bij voorkeur in of nabij Nederland.

3.6.2

RfI potentiele leveranciers centrale registry

Om de keuze voor een leverancier voor te bereiden is in oktober 2010 een RfI uitgestuurd naar alle potentiele leveranciers van een XDS registry. Hierop hebben zes leveranciers gereageerd,: AGFA en E.Novation in combinatie met Forcare software, Topicus, Fysicon/IBM en Oldelft. Accenture gaf aan de dienst aan te willen bieden ism een van de eerder genoemde partijen. Aan de leveranciers is een aantal vragen gesteld.

1. Kwalificatievragen, zoals: a. Uw firma heeft met de aangeboden XDS oplossing op een connectathon in 2009/2010 positief gescoord op de verplichte profielen. b. Geef een aantal referenties van projecten waar de XDS registry nu geïmplementeerd is c. Uw firma heeft voldoende technische expertise en ondersteuning in NL voor deze implementatie. 2. Een indicatie van de prijsstelling, opgedeeld naar een fee per maand voor de registry plus de variabele kosten voor aansluiting per ziekenhuis. 3. Een voorstel met schema hoe uw oplossing voldoet aan gestelde criteria. Plus een beschrijving van de functionaliteit en de regionaal te realiseren randvoorwaarden. We hebben de input gebruikt om de kosten voor de business case te verifieren. Met de leveranciers is afgesproken dat we deze informatie niet beschikbaar stellen.

De algemene conclusie is dat er meerdere leveranciers zijn die voldoen aan de eisen. TIP: IHE XDS is de, maar een nieuwe, internationale standaard voor document- en met name beelduitwisseling. De markt ontwikkelt zich snel en is nog zeker niet verdeeld. Inventariseer daarom op moment van het starten van een project naar de actuele status bij de leveranciers.

Versie 1.0.1

Pagina 12 van 36

4 Projectorganisatie Bij opzetten van een regionaal netwerk zijn vele partijen betrokken. De meeste tijd gaat dan ook zitten in het op 1 lijn krijgen van de vertegenwoordigers van deze partijen. In een ziekenhuis zijn er verschillende personen/rollen die op een of andere manier betrokken zijn en akkoord moeten zijn. In de pilot hebben we gekozen voor een klein projectteam en een bredere stuurgroep met vertegenwoordigers van alle partijen. Daarnaast waren er twee type werkgroepen • •

Een multidisciplinaire werkgroep per ziekenhuis waar de voorbereidingen plaats vonden voor de pilot. Hierin zat de lokale projectleider, netwerkspecialist, PACS beheerder en een radioloog. Een aantal regionale thema gerichte werkgroepen: o Workflow o Business case o Privacy o Architectuur en techniek.

In de periode van de voorbereidingen van de testen was er wekelijks projectleiders overleg. Daarin zaten zowel de projectleiders van de ziekenhuizen als die van de leveranciers van de lokale XDS componenten en de registry (E.Novation). EZDA coördineerde en bewaakte de voortgang. TIP: Zorg bij de start van het project voor enerzijds voldoende betrokkenheid van de aan te sluiten pilotziekenhuizen, inclusief de leveranciers die het meeste werk moeten doen en anderzijds een klein team dat de coördinatie houdt.

4.1 Aanpak testen In ieder project moet er eerst getest worden voordat je live kan gaan. Voor eRadiologie hebben we gekozen voor een aantal combinaties van twee testdagen met een tussenperiode van enkele weken om ontwikkelaars de mogelijkheid te geven aanpassingen te doen. In de tussentijd werden openstaande punten opgelost tussen ziekenhuizen en leveranciers.

In het test plan staat beschreven de werkwijze, de wijze van communiceren, de testcases en de planning. Daarbij gingen wij uit van een testomgeving op iedere locatie, beveiligde (HTTPS) connecties tussen de systemen, een aantal testpatiënten met BSN en set aan beelden. Belangrijke punten van aandacht bij het opzetten van testen zijn:

1. Maak een helder testplan. 2. Spreek testgevallen en verdeling tot in detail af. 3. Test connectiviteit en bereikbaarheid van de systemen vooraf. Bij voorkeur op 1 locatie in connectathon opstelling.

Versie 1.0.1

Pagina 13 van 36

4. Start met testen van ziekenhuis 1 met de registry, vervolgens 2,3, etcetera. 5. Het resultaat van testen is een werkende omgeving. Las een aantal demonstratiemomenten in voor belanghebbenden, omdat testomgevingen nog wel eens wegvallen vanwege andere testactiviteiten. Maak wel afspraken van tevoren voer het aantal en de data van de demonstraties. Dit ivm het beheer van de testomgevingen.

4.2 Facilitaire ondersteuning project

Een project als “transmurale beelduitwisseling” heeft de handicap dat je te maken krijgt met meerdere locaties (ziekenhuizen), meerdere leveranciers (zowel in NL als ontwikkeling in het buitenland) en een multidisciplinair team verdeeld over locaties binnen het ziekenhuis. Dit betekent dat er een aantal eisen gesteld worden aan communicatiemiddelen om informatie en kennis te delen. Handig zijn:

1. Een Sharepoint, projectplace of dergelijke omgeving om documenten te delen en te updaten, anders blijf je updates rondmailen. 2. Regelmatig telefonische conferenties (via KPN of VOIP) zodat je niet hoeft te reizen en vaker overleg kan hebben. 3. Een tool om elkaars schermen te zien, zowel tijdens testen als een demonstratie. Wij gebruikten webex.com, alternatieven zijn er in de vorm van bijvoorbeeld gotomeeting.com

Deze tools werden als zeer waardevol gezien tijdens de korte periode van testen. TIP: De demonstraties verliepen via webex zodat we live konden schakelen tussen de 3 ziekenhuizen en tonen wat daar achter het XDS-scherm zich afspeelde en hoe beelden en verslagen gedisplayd werden in verschillende omgevingen.

4.3 Aandachtspunten bij testen Testen van een XDS infrastructuur kent wat extra uitdagingen vanwege het feit dat het over meerdere locaties en over beveiligde verbindingen plaatsvindt in “vluchtige” testomgevingen. Daarom een aantal tips:

1. Voordat testen op locatie kan plaatsvinden organiseer een testevenement op 1 locatie waar alle XDS repositories en registry tegelijk kunnen testen en configureren. Als de basis configuratie bekend is kan de complexiteit van het netwerk toegevoegd worden. Dit zorgt ervoor dat onderling makkelijker, sneller en beter gecommuniceerd kan worden. 2. De eerste applicatietest start kleinschalig, dus niet met alle ziekenhuizen tegelijk! a. start van ziekenhuis 1 naar de registry (en ATNA rep) met registreren b. Vervolgens ziekenhuis 2 naar de registry met registreren c. Dan ziekenhuis 1 en 2 onderling met ophalen van gegevens. d. Gebruik van een testPACS helpt om te achterhalen waar de problemen zicht bevinden, met name bij nieuwe XDS partijen.

Versie 1.0.1

Pagina 14 van 36

3. Gebruik tijdens het testen communicatiemiddelen zoals webex (scherm overnemen) en skype voor het interactieve gedeelte en een telco faciliteit om regulier op de dag met alle partijen te overleggen.

Versie 1.0.1

Pagina 15 van 36

5 Procesaanpassing/workflow 5.1 Use cases

In de pilot eRadiologie hebben we voor de deelnemende ziekenhuizen een uitgebreide workflow of procesanalyse gedaan voor de belangrijkste radiologie use cases: • • • •

Doorverwijzing Second opinion Intercollegiaal consult Spoed

NB Met name ondersteuning in spoed situaties waarbij direct toegang verkregen kan worden tot de historie van een patiënt is voor specialisten van cruciaal belang. De andere use-cases kan je van tevoren plannen. Van andere projecten hebben we geleerd dat een XDS(-I) infrastructuur vele processen kan ondersteunen waarbij het uitwisselen van documenten en beelden toegevoegde waarde heeft. Je kan daarbij denken aan bijvoorbeeld: •

Het bekijken en verslaan van onderzoeken die elders zijn gemaakt, bijvoorbeeld PET, Radiotherapie, nucleaire geneeskunde et cetera. Dus bijvoorbeeld het maken van een

PET onderzoek in Gouda en het verslaan ervan in Den Haag.

•

Het beschikbaar stellen van informatie in een ander ziekenhuis ter ondersteuning van (multidisciplinair) overleg. Te denken valt aan een hart team bespreking in een hartcentrum (AMC) of regionaal oncologisch multidisciplinair (MDO) overleg.

In de pilot stonden de processen op de radiologie centraal. In de praktijk zijn er vele verschillende samenwerkingssituaties die op een of andere manier de beschikbaarheid van medische gegevens vereisen MET en ZONDER de patiënt op dat moment aanwezig.

Tijdens de pilot hebben we de workflow beschrijvingen heel praktisch beschreven in de volgende paragrafen: 1. 2. 3. 4. 5. 6.

Processchema Event Stappen Resultaat Aannamen Discussiepunten

Het doel van de workflow beschrijving is enerzijds om binnen het ziekenhuis aan betrokken (ICT) medewerkers duidelijk te maken hoe de processen (moeten gaan) lopen. Anderzijds om aan de leveranciers houvast te geven hoe de software ingericht moet worden om deze processen te ondersteunen. Een voorbeeld van deze werkwijze/beschrijving is “doorverwijzen”:

Versie 1.0.1

Pagina 16 van 36

5.2 Voorbeeld doorverwijzen 5.2.1 Processchema

Versie 1.0.1

Pagina 17 van 36

5.2.2 Event Specialist besluit om patiënt door te verwijzen naar een ander ziekenhuis.

5.2.3 Stappen •

• • •

• • •

• • •

Specialist verwijzend ziekenhuis besluit, onder andere op basis van radiologisch onderzoek, de patiënt door te verwijzen naar het ontvangend ziekenhuis. Tevens bepaalt hij dat het relevant is dat het radiologisch onderzoek dat zojuist is gedaan beschikbaar is voor de specialist in het ontvangend ziekenhuis. Specialist verwijzend ziekenhuis licht de patiënt in. Hierbij vraagt hij ook toestemming aan de patiënt om zijn gegevens beschikbaar te stellen voor het ontvangend ziekenhuis. Patiënt geeft zijn toestemming voor het beschikbaar stellen van de resultaten van het radiologisch onderzoek aan het ontvangend ziekenhuis. Specialist verwijzend ziekenhuis legt de toestemming vast en laat de toestemming registreren (‘Invoeren consent’). De specialist stuurt een verwijsbrief naar de specialist in het ontvangend ziekenhuis vanuit zijn EPD. Bij voorkeur via beveiligde e-mail, eventueel per post. De huisarts van de patiënt krijgt hiervan een afschrift. Patiënt maakt een afspraak met specialist ontvangend ziekenhuis. Indien de patiënt nog niet bekend is in het ontvangend ziekenhuis, dan wordt hij voorlopig ingeschreven. Administratief medewerker ontvangend ziekenhuis bereidt de afspraak voor. De medewerker controleert of consent ontvangen is. Specialist ontvangend ziekenhuis bereidt het gesprek met de patiënt voor. De specialist zoekt het onderzoek van het verwijzend ziekenhuis op in de registry (‘Zoeken in registry’). De specialist vraagt het verslag en de beelden op (‘Opvragen verslag en beelden’). Patiënt meldt zich in het ontvangende ziekenhuis voor de afspraak. Als de patiënt bij het maken van de afspraak ingeschreven is, dan wordt zijn BSN geverifieerd. Specialist ontvangend ziekenhuis heeft afspraak met patiënt en heeft de beschikking over het verslag en de relevante beelden uit het verwijzend ziekenhuis. Specialist ontvangend ziekenhuis meldt aan verwijzend specialist de resultaten van de afspraak terug (ZorgMail, telefonisch).

5.2.4 Resultaat •

Patiënt is in behandeling bij ontvangend ziekenhuis.

De volledige procesbeschrijving is beschikbaar via EZDA/Nictiz.

TIP: Beschrijf het gewenste proces in detail, met name de wijze waarop consent wordt geregistreerd.

Versie 1.0.1

Pagina 18 van 36

5.3 Praktijk ervaring Na het testen komt de praktijk. In de pilot zijn we daar niet aan toe gekomen (op dit moment). Dit betekent dat er afhankelijk van de werkwijze een aantal stappen in het proces anders gaan lopen. Belangrijke aandachtpunten daarbij zijn: • •

• •

•

•

Hoe, door wie en op welk moment leg je het patiënt consent vast of kan je dat als impliciet veronderstellen (bij doorverwijzing). Wie krijgen toegang tot de regionale verwijsindex? M.a.w. mogen de radiologen direct beelden opvragen vanuit het PACS of gaat de PACS-beheerder afhankelijk van bijvoorbeeld het mammografieprogramma de beelden van tevoren importeren in het PACS zodat een query op de registry door radiologen niet eens nodig is. Welke procedure hanteren we voor het importeren van beelden en verslagen. Er moet een zgn naming convention zijn voor de beschrijvende gegevens van onderzoeken. De verschillende ziekenhuizen gebruiken niet dezelfde typeringen en coderingen voor type onderzoek, reden aanvraag etc. Tijdens de praktijktesten bleek ook dat de verschillende lokale XDS connectoren niet alle velden van de onderzoeken meegeven en de mapping van velden ook niet correct is. Voor het in productie gaan dient er een regionale lijst van gestandaardiseerde coderingen en typeringen te zijn. Welke afspraken maken we met collega ziekenhuizen in het AD (domein) over o Welke onderzoeken melden we aan (lijst met onderzoeken en historie (max 3 jaar oud) o Voor welk tijdstip (bijv. 13 uur woensdag voor het hart team) o Wie zijn de contactpersonen o Welke (onderdelen) van onderzoeken importeren we wel/niet Stellen we het gebruik van UZI-passen verplicht?

Helaas zijn we aan dit gedeelte (nog) niet toegekomen.

TIP: Start met 1 goed gedefinieerde praktijkcase om ervaring op te doen met de mogelijkheden en breid dit later uit naar andere klinische toepassingen. TIP: Start met 1 goed gedefinieerde praktijkcase om ervaring op te doen met de mogelijkheden en breid dit later uit naar andere klinische domeinen.

Versie 1.0.1

Pagina 19 van 36

6 Privacy De werkgroep Privacy bestond uit een combinatie van juristen, privacy officers, managers en specialisten. In eerste instantie waren er een regionale en landelijke werkgroep maar die is in 2010 bij elkaar gevoegd. Het onderwerp privacy kan niet regionaal en ook niet voor radiologie alleen benaderd worden. Het kent bovendien verschillende aspecten en invalshoeken: 1. Praktische en gewenste werkbaarheid 2. Juridisch en wettelijk kader 3. Technische haalbaarheid

De discussie is nog niet af. We volgen voor eRadiologie de in de maak zijnde gedragscode regionale uitwisseling. Nictiz coördineert vervolgstappen op dit gebied. Voor meer details en de uitwerking verwijzen we naar een aantal andere documenten, zoals het convenant met bijlages.

6.1 Aandachtspunt Gedragscode Elektronische uitwisseling en convenant

In 2010 hebben regio-organisaties en Nictiz het voortouw genomen tot een gedragscode Gedragscode Elektronisch Gegevensuitwisseling in de Zorg (EGiZ) . Doelstelling is deze gedragscode EGiZ voor te leggen aan het CBP en het fiat te krijgen voor de voorgestelde werkwijze en maatregelen met betrekking tot privacybescherming, patiënttoestemming, behandelrelatie enz. In maart/april 2011 wordt de gedragscode na een commentaarronde van de landelijke koepels ter beoordeling aangeboden aan het CBP. De verwachting is dat de gedragscode dit jaar definitief wordt en de gedragscode toegepast kan worden binnen regionale zorgnetwerken. De (concept) gedragscode vormt het uitgangspunt voor het privacybeleid bij de implementatie van een XDS infrastructuur in Amsterdam. In de Gedragscode EGiZ zitten geen handreikingen over;

1. 1. De duur van de toestemmingsperiode, de werkgroep heeft gekozen voor een onbeperkte periode vanaf de toestemming dit dient aangevuld te worden in de Gedragscode EGiZ. 2. 2. De scope van de toestemming (bv. bij aansluiten van andere ziekenhuizen of fusie van regio’s). Voorstel van de werkgroep is de regio vooraf breed te definiëren. Ook de toepassing van alle medische gegevens dient vooraf breed te worden gedefinieerd. 3. 3. De infrastructuur waarmee wijzigingen aan de patiënt gecommuniceerd moeten worden is niet ontwikkeld. Hiervoor dient een patiëntenportaal te worden ontwikkeld. In het aanvullend convenant staan de bovenstaande 3 punten.

6.2 Gedifferentieerd privacybeleid

De werkgroep Privacy stelt voor een gedifferentieerd privacy-beleid te hanteren, waarbij de patiënt uitdrukkelijke (expliciete) toestemming moet verlenen voor regionale gegevensuitwisseling. De toestemming voor gegevensuitwisseling geldt voor zowel beeld als verslag.

Versie 1.0.1

Pagina 20 van 36

Hierbij heeft de patiënt de volgende 4 opties voor privacy-voorkeuren. 4. De patiënt heeft geen bezwaar tegen opname van zijn informatie in het register en tegen raadpleging uit of via dat register. 5. De patiënt heeft geen bezwaar tegen opname van zijn informatie in het register, maar wil per geval van raadpleging toestemming kunnen verlenen. 6. De patiënt bepaalt per onderzoek of deze informatie wel of niet in het register wordt opgenomen. Bij raadpleging van het register zijn er vervolgens twee mogelijkheden. a. De registerinformatie mag zonder toestemming worden geraadpleegd, b. dan wel de patiënt wil (analoog aan 2) per geval van raadpleging toestemming kunnen verlenen. 7. De patiënt wil niet dat er informatie in het register wordt opgenomen.

6.3 Uitganspunten patient consent

Uiteindelijk hebben we de volgende uitgangspunten vastgesteld om de vier opties van gedifferentieerd privacy-beleid te kunnen gebruiken:

1. Iedere patiënt dient uitdrukkelijk toestemming te geven voor publicatie van metagegevens van de onderzoeken in een registry. 2. Er dient een publicatie consent geregistreerd te worden voor opname van gegevens in het regionale XDS registry. 3. Er dient een raadpleeg consent geregistreerd te zijn vooraf door de patiënt of tijdens de raadpleging wordt het raadpleegconsent door geautoriseerde zorgverleners geregistreerd 4. Alleen de onderzoeken van een patiënt die toestemming heeft verleend mogen opgenomen worden in de registry. De centrale registry controleert of er wel een publicatie-consent is. 5. Alle nieuwe onderzoeken van patiënten met publicatie consent worden daarna door de aangesloten ziekenhuizen aangemeld. Er wordt geen historie voor het moment van publicatie consent in het register opgenomen. 6. Het consent is uitdrukkelijk (expliciet), maar hoeft niet perse digitaal vastgelegd te worden, het eerste ziekenhuis dient het te registeren. 7. Het BPPC document waarin de policy staat vermeld staat in de registry opgeslagen. De consumers acteren aan de hand van deze policy. 8. Het consent voor generieke raadpleging geldt voor alle aangesloten ziekenhuizen/artsen binnen de regio (voor het overeengekomen Affinity Domain in Amsterdam) 9. Het consent voor generieke raadpleging geldt voor alle aangesloten ziekenhuizen/artsen binnen de regio en is onbeperkt in de tijdsduur en soort medisch document. 10. Het is wel mogelijk om consent later te wijzigen en in te trekken bij iedere aangesloten instelling op initiatief van de patiënt. De patiënt kan zich bij elke aangesloten instelling melden. Hiervoor dient een patiënten-portaal te worden gedefinieerd. 11. Differentiatie in privacy policy is vanaf de start mogelijk.

Versie 1.0.1

Pagina 21 van 36

6.4 IHE en privacy Aangezien we binnen eRadiologie zoveel mogelijk de internationale IHE profielen volgen kijken we naar de technische mogelijkheden die er zijn. De verplichte profielen zijn: 1. Audit Trail and Node Authentication (ATNA)  beveiliging van communicatie tussen systemen  logging van toegang tot patiëntengegevens 2. Cross-Enterprise User Assertion (XUA en XUA++)  overdragen gebruikersidentificatie (o.a. UZI nummer en rol) 3. Basic Patient Privacy Consent (BPPC)  vastleggen patiënttoestemming in gecodeerde documenten

6.5 Privacy bij start productie

Omdat nog niet alles 100% duidelijk is en bovendien de technische aspecten en werkbaarheid niet bij de start allemaal geregeld kunnen zijn, starten we met een beperkt aantal verwijspatronen tussen ziekenhuizen die op dit moment nauwe samenwerking hebben. Doordat het gaat om gecontroleerde patiënten groepen met een beperkt aantal betrokken medewerkers kunnen de privacy maatregelen ook goed gecontroleerd plaatsvinden. De patiënt geeft toestemming voor de opname in de verwijsindex met zowel NAWgegevens als beschrijvende gegevens van de opgenomen medische documenten. Deze beschrijvende gegevens zijn:

• het soort radiologie onderzoek, • locatie waar het radiologie-onderzoek is uitgevoerd als ook • de aanvragende arts en • de aanvragende afdeling. Er is hiermee sprake van een zogenaamde “gevulde” verwijsindex, aangezien er ook gegevens opgenomen worden over het soort medische gegevens zonder dat deze gegevens ook in de verwijsindex zelf zijn opgenomen. De Wet Bescherming Persoonsgegeven geeft aan dat er expliciete toestemming nodig is voor opname in deze verwijsindexindex, aangezien er uit de beschrijvende gegevens persoonlijke medische episode(s) zijn af te leiden. Dit betekent dat de patiënt toestemming moet verlenen voor aanmelding in het XDS register en publicatie van verwijsgegevens. Automatische aanmelding van alle onderzoeken is dus niet mogelijk.

Deze aanpak is een eerste stap op weg naar een ideale situatie. Dit zal niet in 1 dag geregeld zijn. Daarom zullen de regio’s de komende jaren samen met Nictiz toewerken naar een zo optimaal mogelijke werkwijze en ondersteunende wetgeving. TIP: Start met een lager ambitie niveau qua schaal van de verwijsindex. Kies voor een patiëntengroep waarbij de privacy-maatregelen zijn te implementeren

Versie 1.0.1

Pagina 22 van 36

7 Business case en model Tijdens de pilot hebben zowel het business model als de business case uitgewerkt voor de regio Amsterdam. Voor het opzetten van de business case en uitwerken van de business modellen is de volgende werkwijze gehanteerd:

1. De radiologieafdelingen van alle EZDA ziekenhuizen zijn geënquêteerd. 2. Aan een aantal in Nederland actieve leveranciers is een RfI (request for information) opgevraagd, om actuele marktprijzen en haalbaarheid te verifiëren. Zes leveranciers hebben gereageerd.

7.1 Businessmodel

Voor EZDA of een organisatie die van plan is beelduitwisseling te faciliteren, is het van belang te kijken naar de wijze waarop de centrale componenten worden ingekocht en aangeboden aan participerende instellingen.

7.1.1 Aanbod model In de huidige markt voor een regionale (beelden-)dienst zijn een aantal aanbieders actief en nog meer in opkomst. Zij bieden een dienst aan conform IHE XDS en bijbehorende profielen of op een “proprietary” of eigen wijze. De modellen die wij tegen zijn gekomen zijn: 1. Aanschaf van software en een onderhoudscontract, met als variabelen: a. Aantal domeinen (radiologie, cardiologie etc) b. Aantal documenten dat uitgewisseld kan worden c. Aantal aangesloten instellingen d. Aantal aangesloten systemen (Source/repository) e. Aantal viewing licenties (consumers) 2. Aanschaf van een dienst (Software As A Service (SAAS)) a. Per maand/jaar b. Op basis van gebruik (aantal aanmeldingen, opvragingen, gebruikers)

In bijna alle gevallen komt daarbij initieel een aantal mandagen installatie en configuratie plus benodigde hardware en hosting.

7.1.2 Verdeelsleutel Om deze kosten door te belasten naar de deelnemende partijen zijn er een aantal verdeelsleutels mogelijk. Dit kan zijn op basis van:

1. Gelijkheid: iedereen betaald evenveel. 2. Onderlinge verdeelsleutel: afhankelijk van onderlinge afspraken, bijvoorbeeld: omzet, aantal bedden, aantal gemaakte onderzoeken op afdeling radiologie, etcetera. 3. Gebruik: bijvoorbeeld aantal aangemelde documenten of aantal opvragingen.

Daarbij komen de initiële installatie en configuratie (mandagen).

Versie 1.0.1

Pagina 23 van 36

Voor EZDA kiezen we er voor dat instellingen kunnen aansluiten voor een initiële installatie fee plus maandelijkse kosten volgens de reguliere EZDA verdeelsleutel ten behoeve van de jaarlijkse participantenbijdragen.

Een alternatief model is om bij de start de initiële kosten te verdelen tussen de deelnemende partijen. Zodra een nieuwe partij toetreedt betaalt deze partij een deel van de opstartkosten terug aan de initiatiefnemers.

7.2 Businesscase

Bij het opstellen van de business case was de volledige vervanging van de CD stromen tussen de ziekenhuizen het uitgangspunt.

De business case is volledig afhankelijk van de aannames. In onze business case berekeningen zijn we de volgende uitdagingen tegen gekomen:

1. Praktijk gegevens zijn moeilijk te verkrijgen, omdat niet alles wordt geregistreerd. Denk daarbij aan aantal CD’s dat geïmporteerd/geëxporteerd wordt binnen de regio. 2. Baten, maar ook het verwachte gebruik in de toekomst zijn grove schattingen. De baten zijn met name kwalitatief van aard. 3. Kosten aan de kant van ziekenhuis zijn niet allemaal direct toe te rekenen aan een afdeling (radiologie).

EZDA heeft er voor gekozen om alleen naar de kosten/baten van de radiologie te kijken. Echter een radiologieafdeling staat ten dienste van allerlei specialismen die beelden gebruiken voor verschillende klinische processen, zoals tijdens OK, second opinion of tijdens besprekingen.

De directe kosten van beelduitwisseling op de huidige manier met CD’s vergelijken we met de nieuwe manier van het beschikbaar stellen van beelden en verslagen. Hierdoor kunnen processen geoptimaliseerd worden en daarbij zijn er veel indirecte baten, zowel in kwaliteit van zorg als logistiek (en dus kosten besparend). Echter wanneer beelden voortaan on-line beschikbaar zijn over instellingen heen kunnen nieuwe patronen ontstaan en daarmee een heel ander gebruikspatroon. Daarmee is op voorhand lastig te bepalen wat het gebruik zal zijn. We hebben dit vergeleken met het digitaliseren van huisartsenbrieven. Vroeger ging dat op papier en met de post. Nu is dat via Edifact berichtenverkeer. Het tarief van edifact is gebaseerd op het verzenden van 1 brief analoog aan de oude brief. Omdat het veel gemakkelijker is om elektronisch en automatisch brieven te versturen is het aantal brieven bijna vertienvoudigd t.o.v. de analoge werkwijze. Destijds is de business case bepaald op het aantal brieven vermenigvuldigd met de kosten (handelingen, papier, printer, postzegel enveloppe). Edifact leek veel goedkoper per bericht, echter het aantal berichten is vele malen hoger.

Als we deze redenering toepassen op eRadiologie dan zou het kunnen zijn dat niet 3% van de onderzoeken die nu op CD worden gezet uitgewisseld worden maar een veelvoud daarvan. Daartegenover staat dat een x% hiervan bij directe beschikbaarheid niet over hoeft te worden gedaan in het ziekenhuis waar de patiënt heen gaat. Kortom: wij hebben bij de EZDA berekeningen de volgende aannames gedaan per ziekenhuis: Versie 1.0.1

Pagina 24 van 36

1. Kosten om lokale RIS/PACS aan te passen verschillen per ziekenhuis. Wij rekenen afhankelijk van de grootte en situatie met initieel tussen €10.000 en €50.000 2. Kosten voor de centrale component afhankelijk van het aantal deelnemende instellingen, domein en aantal documenten initieel tussen €10.000 en €30.000 en per jaar tussen €20.000 en €50.000.

De baten zijn voor het ziekenhuis te verdelen in:

1. Directe besparingen gerelateerd aan CD handelingen. Hierbij maken we

onderscheid tussen het exporteren en importeren. Dit zijn personeelskosten FTE, CD’s, transport en bij het importeren de extra opslag in het PACS. NB: in een infrastructuur waar onderzoeken direct beschikbaar zijn kan het gebruik bijhoorlijk gaan afwijken van het huidig gebruik van CD’s. Over 5 jaar zeggen we waarschijnlijk dat we nooit meer terug kunnen naar de tijd van de CD!

2. Indirecte besparingen zijn o.a. logistieke winsten zoals minder ligdagen omdat een patiënt eerder besproken/geholpen kan worden, vermijdbare onderzoeken (niet overdoen), vermijdbaar transport van patiënten omdat op een andere locatie diagnostiek of RT-planning plaatsvindt dan waar de beelden gemaakt zijn.

De financiële business case kent de volgende componenten. Voor elk ziekenhuis gelden andere getallen en aannames. Hierbij een overzicht van te hanteren grootheden.

Versie 1.0.1

Pagina 25 van 36

Vanwege de vele aannames en onzekerheden bij de indirecte besparingen hebben we deze niet meegerekend in onze regionale business case. Echter hier zit wel het grootste belang voor de business case per ziekenhuis om deel te nemen aan dit initiatief. Een van de academische ziekenhuizen heeft een inschatting gemaakt van het aantal CT’s en MRI’s die mogelijk niet nodig zouden zijn geweest als deze onderzoeken bij de doorverwijzing direct beschikbaar zouden zijn geweest. Dit komt op een indicatieve besparing van ruim 190.000 euro per jaar. Door kwalitatieve baten neemt gebruik van een beeldendienst waarschijnlijk toe, waardoor ook de kosten van de dienst zullen stijgen. De meeste voordelen zijn te behalen als alle onderzoeken aangemeld kunnen/mogen worden. Dan is bijvoorbeeld ook in een SEH situatie alle beeldmateriaal van een patiënt ter beschikking. Echter bij een groter aantal aangesloten instellingen worden een deel van de kosten door dit zelfde grotere aantal gedeeld. Al met al is de vraag hoe relevant deze kostenbenadering is. TIP: Zoek voor het starten van een beeldendienst voor een positieve lokale business case eerst naar een goede casus waar beelduitwisseling een belangrijke of strategische keuze is. Dan zijn er meer baten c.q. voordelen te vinden dan sec het vervangen van CD-verkeer.

Versie 1.0.1

Pagina 26 van 36

8 Technische infrastructuur 8.1 Netwerk Binnen de pilot wisselen we beelden en verslagen uit over het beveiligde glasvezelnetwerk van de Amsterdamse ziekenhuizen (MANza 6) . Daarbij is gebruik gemaakt van statische routering. Dit betekent dat we alle systemen die met elkaar moeten communiceren toelaten tot elkaar. Dit kostte meer tijd dan we hadden voorzien en heeft het testen enigszins opgehouden. NB voor het AMC zou de test op deze korte termijn niet eens gerealiseerd zijn als we niet over de beveiliging van het MANza netwerk zouden beschikken.

8.2 Aandachtpunten configuratie netwerk

Tijdens de pilot zijn we tegen een aantal zaken aangelopen bij het configureren van het netwerk. Belangrijk zijn de volgende zaken:

1. Maak een netwerkoverzicht met daarin alle actoren (lees systemen) die gegevens

uitwisselen, zowel XDS als XDS-I en ook DICOM voor de PACS2PACS uitwisseling. NB: Een voorbeeld is beschikbaar van het OLVG en AMC.

2. Bepaal de route tussen de verschillende servers. a. Gebruik daarbij verplicht publieke IP adressen b. NAT-ing is mogelijk maar niet wenselijk c. Maak gebruik van echte domein namen en een DNS server d. Gebruik dynamische routering in de centrale om 1op1 netwerkroutes te voorkomen en opschaling te kunnen faciliteren. 3. Ieder ziekenhuis heeft minimaal 1 maar vaker meerdere firewalls waar de servers achter hangen. TIP: gebruik dezelfde poortnummers voor de services in ieder ziekenhuis en bereid dat tijdig voor. Bijvoorbeeld DICOM op poort 104. NB: Nictiz gaat een landelijk nummer aanvragen bij IANA (Internet Assigned Numbers Authority)

4. Neem de tijd voordat je gaat testen om het netwerk gereed te maken: a. Start met een netwerk ping test door alle partijen! b. Gebruik telnet om de poorten te testen vanaf het IP-adres of subnet waar vandaan getest gaat worden 5. Er moet een zgn naming convention zijn voor een aantal zaken. Het projectmanagement houdt deze zaken bij: a. Test patiënten (NB: wij maakten gebruik van testpatiënt gegevens van Nictiz, echter die zijn onbekend in testsystemen van de ziekenhuizen, dus lastig door de hele keten van ZISRIS-PACS-XDS te testen.)

b. Systemen en hun rollen c. IP adressen en poortnummers d. AE titles voor de PACSen die DICOM communicatie (moeten) doen. (NB: in

principe gaan we binnen XDS-Ib uit van WADO services en speelt dit geen rol, maar tijdens de test bleek dat niet altijd mogelijk.)

6. Het gebruik van UZI servercertificaten is verplicht binnen de AORTA infrastructuur. Omdat eRadiologie op termijn zal opschalen naar het LSP is het verstandig ook gebruik te maken van UZI-servercertificaten. Deze moeten wel op 6

MANza = Metropolitan Area Network ziekenhuizen amsterdam

Versie 1.0.1

Pagina 27 van 36

tijd aangevraagd worden bij het UZI-register.

TIP: Ga voordat je op locatie gaat testen eerst een dag testen op 1 locatie met alle partijen, om de basis configuratie vast te stellen.

8.3 Uitgangspunten architectuur beveiliging eRadiologie

In de eRadiologie architectuur staan een aantal uitgangspunten en aanbevelingen om te voldoen aan zowel Nictiz eisen als verplichtingen conform de gebruikte IHE ITI profielen. Belangrijke punten zijn: 1. 2. 3. 4. 5.

Transportbeveiliging met SSL/TLS Wederzijdse authenticatie via UZI server certificaat Berichtbeveiliging met authenticatietoken Beveiliging is onafhankelijk van transport protocol Berichten met security tokens uitrusten onafhankelijk van authenticatie- en autorisatiemechanisme 6. Autorisatiepolicy kan met BPPC worden ingevuld, echter wel verplicht stellen bij XDS leveranciers 7. Landelijk is op termijn de UZI pas verplicht, echter regionaal kan je besluiten dat personen geautoriseerd worden door de ziekenhuizen zelf op basis van hun Ziekenhuis ID en bijbehoren rechten en toegang tot de XDS infrastructuur.

8.4 Aanpak techniek binnen ziekenhuis

De ziekenhuizen zijn zelf verantwoordelijk voor de selectie, keuze en implementatie van de lokale XDS-stekkers. Deze connectoren hebben de specificatie die door de gekozen leveranciers wordt aangeboden. Tijdens de pilot is voor de ziekenhuizen een “aansluitdocument“ gemaakt waarin in detail staat op welke wijze de XDS actoren worden ingevuld in dat ziekenhuis. Belangrijke voorwaarde is het gebruik van BSN als unieke identifier en de mogelijkheid om het ZIS te bevragen (een zogenaamde PIX query) om het lokale ZIS nummer te krijgen en toe te voegen aan de beelden en verslagen, zodat deze in het lokale RIS/PACS opgenomen kunnen worden en toonbaar worden via de EPD portal. In de pilot hebben we bij het OLVG, AMC en Bovenij de volgende stappen doorlopen. Dit zelfde stappenplan geldt voor ieder aan te sluiten ziekenhuis. Nr 1 2 3 4

Activiteit

Omschrijving

Workshop technisch ontwerp (per ziekenhuis)

In een gezamenlijke sessie met medewerkers van het ziekenhuis, het regionale project en de betrokken leverancier(s) wordt een technisch ontwerp gemaakt van de benodigde lokale implementatie.

Installatie en configuratie

RIS en PACS worden geconfigureerd om verslagen en beelden te exporteren en importeren.

Selectie componenten

EPD registry viewing

Versie 1.0.1

Afhankelijk van de lokale mogelijkheden ondersteunen we bij de selectie van de connectoren. De beelden vanuit andere bronnen moeten via de webviewer in het EPD zichtbaar worden. De technische en functionele

Pagina 28 van 36

uitwerking moet per ziekenhuis bepaald worden.

5

Testen

6

Plan van aanpak implementatie lokale componenten

7

Plan van aanpak opschaling binnen ziekenhuizen

Zodra de ziekenhuizen met de registry kunnen communiceren zal per ziekenhuis getest kunnen worden met het registreren van onderzoeken en het binnenhalen ervan.

Aan het eind van de pilot ontwikkelt elk ziekenhuis een plan van aanpak om de lokale component in productie te kunnen nemen.

In samenhang met de voorgaande activiteit, en in onderling overleg tussen de ziekenhuizen, ontwikkelt elk ziekenhuis een plan van aanpak om vanuit de pilot binnen het ziekenhuis op te schalen naar meer werkprocessen en/of andere beelddomeinen.

8.5 Ziekenhuis infrastructuur voor alle beelden

De pilot is gericht geweest op het delen van radiologische informatie tussen zorgverleners in ziekenhuizen. XDS is in principe breder toepasbaar. Daarom is het van belang bij aanvang van het initiële project te kijken naar de verschillende systemen die in het proces gebruikt worden, m.a.w. de informatiebronnen (XDS sources). In het geval van radiologie zijn dat: • • •

Het RIS waar het verslag staat Het PACS waar de beelden staan Het PACS (voor de radiologen) en het EPD (voor de specialisten) het systeem van waaruit een query op de registry wordt gedaan om te zien of er documenten beschikbaar zijn

Binnen het ziekenhuis zijn er echter nog een aantal systemen die gekoppeld kunnen worden: •

•

• •

Via een HL7 PIX query wordt bij het interne ziekenhuis patiënt ID het bijbehorende BSN opgevraagd bij het ZIS en vice versa Een DMWL query is handig om bij het importeren van een onderzoek (automatisch) een accesssionnummer te genereren en het juiste lokale patiënt ID toe te voegen aan de DICOM header om vervolgens de beelden te importeren in het lokale PACS. Eventueel een broker om het verslag of de DICOM beelden te vertalen naar een XDS transactie De HL7 broker (zoals Cloverleaf) kan ingezet worden om verslagen om te zetten van HL7 v2 ORU naar HL7 v3 CDA

In het geval van cardiologie zijn dat: • • • •

Het cardio-echo PACS Het cathlab PACS en CVIS (Cardiovascular Information System) Het ECG management systeem Het digitale dossier met relevante patiënt gegevens.

Versie 1.0.1

Pagina 29 van 36

Zo is dit voor elk ziekenhuis en elk klinische domein weer anders en afhankelijk van de te koppelen systemen. De gebruikte standaard interfaces blijven wel gelijk conform de IHE profielen.

8.6 Aansluitdocument

Binnen de pilot hebben we voor ieder ziekenhuis een zogenaamd aansluitdocument gemaakt. Hierin staat precies beschreven welk systeem gekoppeld wordt en welke koppelingen daarvoor gemaakt moeten worden en volgens welke standaard. Als voorbeeld staat het schema van het AMC getoond.

Hierin is duidelijk te zien dat er een aantal vertaalslagen zijn. Als voorbeeld het verslag: • • •

Het RIS stuurt HL7 ORU bericht naar cloverleaf / HL7 broker Cloverleaf vertaalt naar HL7 v3 CDA XDS-broker vertaalt dit naar een XDS submission naar de registry. TIP: Voor het uitzoeken hoe systemen XDS-enabled kunnen worden: maak daarvoor een aansluitdocument met daarin alle koppelingen. Ieder systeem is te koppelen via een XDS-broker!

8.7 Regionale infra In de regio zal een verwijsindex moeten komen. Daarbij horen een aantal extra services, waaronder logging (ATNA) en eventueel koppelingen naar andere regio’s (XCA) en het ondersteunen van privacy policies (BPPC). Versie 1.0.1

Pagina 30 van 36

In de EZDA pilot hebben we gekozen voor een eigen hardware omgeving en het huren van de software voor een testperiode.

Voor het netwerk zijn een aantal voorzieningen nodig qua beveiliging en routering. Zie hiervoor later.

8.8 Aansluiting LSP

Nictiz is op dit moment bezig met een verkenning van de (on)mogelijkheden om de landelijke infrastructuur AORTA uit te breiden met onderdelen uit het IHE ITI domein (zoals beschreven in de profielen IHE XDS-I, BPPC en XCA). Bij het ontwerp van de architectuur7 van het programma eRadiologie worden de volgende uitgangspunten gehanteerd: •

• • •

• • •

•

Confirmeren aan bestaande wet- en regelgeving, zoals de Wet op de Geneeskundige Behandelingsovereenkomst (WGBo) en de Wet Bescherming Persoonsgegevens (WBP). Identificatie van patiënten middels het landelijke Burger Service Nummer (BSN). Identificatie en authenticatie van zorgverleners middels de UZI-pas. Aangesloten zorginformatiesystemen (Repositories van RIS en PACS) moeten aan eisen voldoen ten aanzien van beveiliging en beheer, conform de eisen van een goed beheerd zorgsysteem (GBZ). Deze eisen omvatten zowel procedurele, functionele als technische aspecten (interfaces) en hebben betrekking op het zorg dragen voor integere, actuele, volledige patiëntgegevens. De aangesloten zorgsystemen kennen het adres van het andere zorgsysteem (bijvoorbeeld via de VWI, het Zorgadresboek (ZAB) of anders (nog niet gedefinieerd)). De autorisatie- en logging services leveren alleen autorisatie aan zorgverleners, niet aan de patiënt. De autorisatie- en logging services verlenen zorgverleners autorisatie voor toegang tot patiëntgegevens op basis van de rol van de zorgverlener (vastgelegd volgens het autorisatieprotocol) en houden rekening met de eventueel vastgelegde wensen van de patiënt (in het patiëntenprofiel). De zorgapplicatie verleent de zorgverlener op basis van deze autorisatie toegang tot patiëntgegevens. Alleen tokenauthenticatie wordt ondersteund.

Onderstaand figuur toont de architectuur van Aorta inclusief XDS-I.

7

Uit notitie verkenning XDS-Aorta van H. Hutink, Nictiz nov 2010

Versie 1.0.1

Pagina 31 van 36

Om aan te sluiten binnen deze infrastructuur gaan in de toekomst een aantal nieuwe eisen gelden, zoals gedefinieerd voor systemen door Nictiz.

Om ene landelijke infrastructuur te realiseren waar zorgverleners beelden en andere documenten op een veilige manier conform de geldende wetgeving te kunnen uitwisselen is aanpassing van de huidige infrastructuur (Aorta) noodzakelijk. Daarom heeft Nictiz in 2010 een verkenning naar de mogelijkheden voor gebruik van XDS gedaan. Daaruit komen aan aantal aanbevelingen en eisen waar een regionale XDS infrastructuur in de toekomst rekening mee moet gaan houden. Algemeen •

Document Source, Document Registry, Document Repositories en Document Consumer zullen aan GBZ eisen moeten voldoen en zich melden bij het applicatie register.

Identificatie/authenticatie • • • •

De XDS consumers (dus in de praktijk EPD, PACS en RIS maken gebruik van persoonsgebonden UZI passen. De verbinding tussen Repository (RIS/PACS) en het LSP moet een beveiligde verbinding zijn, die voldoet aan de eisen die binnen de AORTA worden gehanteerd. De Repositories (PACS en RIS) moeten bij het SBV-Z of een ander partij gevalideerde BSN’s gebruiken. Wederzijdse authenticatie tussen GBZ’en. (nu gebeurt dat alleen tussen LSP en GBZ). Een GBZ moet alle andere GBZ‘en kunnen authenticeren. De GBZ’en kennen nu alleen het LSP als betrouwbare partij. Nu moet iedere partij die een UZI server certificaat gebruikt kunnen authenticeren. Dit betekent extra GBZ eisen.

Autorisatie • •

De GBZ’en moeten op een beveiligde manier aansluiten op de generieke services (autorisatie- en logging service). Elk systeem dat beeldgegevens (niet verslaggegevens) ophaalt moet SAML technologie ondersteunen voor het handhaven van autorisatie (XUA).

Versie 1.0.1

Pagina 32 van 36

•

Elke regio moet bij aansluiting op AORTA voldoen aan het landelijk informed consent en bijbehorende autorisatieprofielen van de patiënten. Het patiënt consent profiel van IHE (BPPC) is dus niet nodig voor AORTA en zal dan ook niet ondersteund worden.

Logging •

De GBZ’en moeten via de logging service de centrale logging aanvullen via een beveiligde verbinding. Het LSP moet kennis hebben van de berichtuitwisseling tussen GBZ’en. Dus de inrichting van keten logging tussen PACS – PACS (beelduitwisseling) zichtbaar maken op het LSP.

GBZ eisen •

De Document Registry is een nieuw domein naast een GBZ en ZSP, namelijk GBR een Goed Beheerd Registry. GBR krijgt zijn eigen programma van eisen, dan wel extra eisen bovenop de geldende GBX eisen.

Over verdere details beschikken we op dit moment niet. In 2011 zal dit verder uitgewerkt moeten worden. In het architectuurdocument eRadiologie staan veel meer details over deze verkenning. TIP: Zorg er voor dat je aanhaakt bij de landelijke bijeenkomsten en contact onderhoud met het programma eRadiologie om goed op de hoogte te blijven van de landelijke ontwikkelingen.

Versie 1.0.1

Pagina 33 van 36

9 Tips op een rij Na de pilot hebben we een intensieve evaluatiesessie georganiseerd, waarbij alle leveranciers, ziekenhuizen en EZDA aan meewerkten. Dit resulteerde in onderstaande conclusies over enerzijds de zaken die goed zijn gegaan en anderzijds de zaken die achteraf beter hadden gekund.

9.1 Sterke punten pilot

1. Testomgeving benaderde de praktijk/productie situatie in test (real live). De systemen stonden in de ziekenhuizen (testomgevingen) en waren gekoppeld via de MANza ring. 2. Gebruik van (tele)communicatie via telco en webex, ivm multilocatie testen 3. Duidelijke use cases, i.c. doorverwijzen. 4. Presentatie van demo We hebben een aantal live demonstraties gegeven waarbij we via webex konden wisselen tussen de ziekenhuizen 5. De gebruikers geven aan dat XDS functionaliteit zoals gebruikt in PACS zeer gebruikersvriendelijk is. 6. Alle deelnemers tijdens de pilot hadden de drive en inzet om echt resultaat te behalen en te demonstreren. Dit was erg positief. (leveranciers en ziekenhuizen)

9.2 Verbeterpunten

1. Technische specificatie moeten meer op detail nivo gesteld worden, dwz: a. Profielen (verplicht/niet verplicht) (BPPC, WADO, XUA, PIX,…) b. Naming convention metadata (IP, AE, Instelling, portnumbers, test patiënten, studiedata, beelddata, configuratie velden in XDS KOS, …) Tijdens de pilot gebruikte iedereen zijn eigen naamgeving. Dit is niet te beheren en voor de gebruiker te gebruiken. c. Standaardisatie van meta-data op klinisch gebied. Denk daarbij aan naamgeving van bodyparts, onderzoeken, diagnoses etcetera. 2. Sturing en opdrachtgeverschap is erg belangrijk a. Het voortraject duurde erg lang. Sneller escaleren naar RvB ziekenhuizen zou beter zijn geweest. b. Commitment van opdrachtgevers moet niet alleen op papier staan, maar ook resulteren in de aanschaf van de software en implementatie. 3. Gebruik van faciliterende ICT is essentieel om efficiënt te testen en configureren. a. Sharepoint (voor de documenten) b. Webex (om schermen te tonen) c. Telco (om locatieafhankelijk te kunnen vergaderen)

9.3 Voordeel deelname aan pilots

1. Deelname en de demonstratie is PR voor zowel leverancier als ziekenhuis als IHE 2. Je doet veel ervaring en detail kennis op met nieuwe technologie en standaarden 3. Deelname geeft inzicht in inzetbaarheid van nieuwe technologie in breder perspectief (XDS is content agnostisch)

Versie 1.0.1

Pagina 34 van 36

9.4 Wat moeten we nog doen binnen de regio voor go live? 1. Besluitvorming deelnemende ziekenhuizen 2. Duidelijkheid privacy policy binnen domein/regio, voorstel is gedaan door de werkgroep Privacy, expliciet consent en gedifferentieerd beleid 3. Eenduidige autorisatie-tabel waarbij de behandelrelatie voor raadpleging is te controleren ontwikkelen 4. Productie omgeving van de centrale infrastructuur, dwz: a. Dynamische routering ipv P2P in het MANza netwerk b. Aanschaf hardware en software 5. Lokale aanpassingen XDS in ziekenhuis. Dit is verschillend voor ieder ziekenhuis a. Oplossen van non-conformance (bijvoorbeeld ondersteuning BPPC, XUA, WADO etc) b. EPD integratie om gebruikers in de kliniek toegang te geven tot beelden van buiten het ziekenhuis. c. Koppelingen tussen RIS/PACS en XDS componenten (DICOM, ADT, ORU) d. Koppelingen tussen XDS component en ZIS (PIX en HL7 broker) e. Registratie en inloggen van gebruikers die toegang krijgen tot de XDS infrastructuur. We gaan in principe uit van UZI-pas. Echter tot nu toe worden die niet gebruikt in ziekenhuizen en (bijna) niet ondersteund door PACS en EPD systemen. Dit vergt zeker nog nader onderzoek en ondersteuning omdat het om internationale leveranciers gaat.

9.5 Wat moeten we nog doen bij Nictiz/VWS?

1. Privacy is het allergrootste probleem om op dit moment zomaar een XDS infrastructuur te gebruiken. 2. De huidige ideeën over de Aorta infrastructuur in combinatie met (meerdere) registries moeten verder uitgewerkt worden. Dit is met name belangrijk als we tussen regio’s gaan uitwisselen of XDS breder inzetten 3. Nationale testevents met verschillende leveranciers is belangrijk, omdat in iedere regio ander leveranciers gaan aansluiten. Met name als we over nieuwe profielen praten of nieuwe leveranciers voor het eerst willen aansluiten. 4. Duidelijke richtlijnen voor gebruik UZI pas, servercertificaten en gebruik encryptie voor XDS infrastructuren buiten Aorta.

Versie 1.0.1

Pagina 35 van 36

10 Bibliotheek Er zijn een aantal documenten relevant in het kader van een project eRadiologie. Hier staan de verwijzingen en de plek waar je die kan vinden. In principe zijn de meeste documenten via EZDA of Nictiz te verkrijgen. Privacy documenten

1. Eindrapportage werkgroep Privacy 2. Gedragscode Regionale uitwisseling (concept) 3. Convenant regionale uitwisseling (concept) Architectuur

4. Architectuur eRadiologie (concept) 5. IHE achtergrond documenten 6. Voorbeeld aansluitdocument lokale XDS infrastructuur (AMC) Businesscase/model

wiki.ihe.net

7. Eindrapportage Businesscase/model 8. Invul spreadsheet businesscase berekening ziekenhuis Workflow

9. Procesbeschrijving eRadiologie

Projectdocumenten

10. Concept projectplan eRadiologie lokale component 11. Kennisartikel verbreding eRadiologie

Voor meer informatie of een toelichting kunt u contact opnemen met de volgende personen: Jeroen Straatman, directeur EZDA

[email protected]

Henk Hutink, programmamanager eRadiologie Nictiz

[email protected]

Hans Mekenkamp, projectleider, MedicalPHIT

Mark Meier, radioloog AMC, ICT commissie NVvR

Versie 1.0.1

[email protected] [email protected]

Pagina 36 van 36