Evaluatie pilot eradiologie. Hans Mekenkamp. Projectleider. Versie: 1.0. Datum: 15-03-2011

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 3.1 DE IHE XDS OPLOSSING... 7 BESCHRIJVING VAN DE IHE XDS INFRASTRUCTUUR... 7 3.2 OPSCHALING KLINISCHE DOMEINEN... 7 3.3 IHE PROFIELEN... 8 3.4 IHE CONFORMANCE LEVERANCIERS... 10 3.5 BEVINDINGEN XDS-INFRASTRUCTUUR... 11 3.5.1 IHE CONFORMANCE TESTEN LOKALE XDS COMPONENTEN... 11 3.6 IHE CONFORMANCE IN NEDERLAND... 11 3.6.1 LEVERANCIERS CENTRALE COMPONENT IN DE REGIO... 12 3.6.2 RFI POTENTIELE LEVERANCIERS CENTRALE REGISTRY... 12 4 4.1 PROJECTORGANISATIE... 13 AANPAK TESTEN... 13 4.2 FACILITAIRE ONDERSTEUNING PROJECT... 14 4.3 AANDACHTSPUNTEN BIJ TESTEN... 14 5 5.1 PROCESAANPASSING/WORKFLOW... 16 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 PRIVACY... 20 AANDACHTSPUNT GEDRAGSCODE ELEKTRONISCHE UITWISSELING EN CONVENANT... 20 6.2 GEDIFFERENTIEERD PRIVACYBELEID... 20 6.3 UITGANSPUNTEN PATIENT CONSENT... 21 6.4 IHE EN PRIVACY... 22 6.5 PRIVACY BIJ START PRODUCTIE... 22 7 7.1 BUSINESS CASE EN MODEL... 23 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 TECHNISCHE INFRASTRUCTUUR... 27 NETWERK... 27 8.2 AANDACHTPUNTEN CONFIGURATIE NETWERK... 27 8.3 UITGANGSPUNTEN ARCHITECTUUR BEVEILIGING ERADIOLOGIE... 28 8.4 AANPAK TECHNIEK BINNEN ZIEKENHUIS... 28 8.5 ZIEKENHUIS INFRASTRUCTUUR VOOR ALLE BEELDEN... 29 8.6 AANSLUITDOCUMENT... 30 8.7 REGIONALE INFRA... 30 8.8 AANSLUITING LSP... 31 9 9.1 TIPS OP EEN RIJ... 34 STERKE PUNTEN PILOT... 34 9.2 VERBETERPUNTEN... 34 9.3 VOORDEEL DEELNAME AAN PILOTS... 34 9.4 WAT MOETEN WE NOG DOEN BINNEN DE REGIO VOOR GO LIVE?... 35 9.5 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 beelden Registry 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. Workflow 2. Businesscase 3. Privacy 4. 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 documenten 1. Ook zijn onderdelen van de infrastructuur geschikt voor hergebruik binnen de regio. 1 e 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 MammoXL 2 ). 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 HL7 Clinical Document Architecture (CDA) 2 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. Processchema 2. Event 3. Stappen 4. Resultaat 5. Aannamen 6. 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