Advies infrastructuur voor uitwisseling van de generieke overdrachtsgegevens in Nederland

Transcriptie

1 Advies infrastructuur voor uitwisseling van de generieke overdrachtsgegevens in Nederland

2 Inhoud 1. Aanleiding en Samenvatting 2. Uitwerking samenwerkingsvormen en informatieuitwisselingspatronen 3. Geadviseerde vervolgstappen Bijlagen

3 Aanleiding en Samenvatting

4 Aanleiding en opstellen van het advies Vraag van de Stuurgroep van Programmadirecteuren EPD aan de AcZie om: Uw advies en uw standpunt met betrekking tot de gewenste infrastructuur 1 voor de uitwisseling van generieke overdrachtsgegevens tussen ziekenhuizen in Nederland. Ook is er behoefte aan een breedgedragen oplossing bij andere initiatieven In alle initiatieven wordt gezocht naar manieren om patiëntinformatie te delen tussen zorgverleners in verschillende organisaties. Voorbeelden van de verschillende initiatieven: Het project 'Landelijk Doorverwijzen', een initiatief van Alpe D HuZes, beoogt in 2013 tot een implementatieplan te komen voor landelijk verwijzen; Ondersteunen van Oncologisch MDO, pilot projecten vanuit IKNL; Samenwerking tussen het UMC Utrecht met het AvL en het Princes Maxima Centrum; Regionale uitwisseling van informatie vanuit diverse regionale schakelpunten. Voor al deze initiatieven is het nodig dat er een infrastructuur beschikbaar komt om informatie over uit te wisselen. Het is voor alle partijen van belang dat er een oplossing komt waarmee daadwerkelijk informatie is uit te wisselen via een breed gedragen oplossing. Hoe is dit advies tot stand gekomen In mei heeft de SIG PRIMA een eerste advies opgesteld; naar aanleiding van dat advies is een bredere werkgroep samengesteld met vertegenwoordigers uit de UMC s, Nictiz, EZDA, Sleutelnet en het project Landelijk doorverwijzen (Alp d Huzes, Soulve). Dit advies is tot stand gekomen na een workshop, afstemming met de leden van genoemde werkgroep via mail en bespreking in de SIG PRIMA vergadering van 19 september. 4 1 Onder infrastructuur wordt in dit verband verstaan: aspecten als netwerk connectiviteit, authenticatie/autorisatie/logging, patiëntrechten, adresboeken, versturen of opvragen (push versus pull) en beheer.

5 Bij de totstandkoming van het advies is als volgt te werk gegaan (1/2) Eerst is gekeken welke vormen van communicatie en informatieoverdracht (samenwerkingsmodellen) ondersteund moeten worden. De conclusie is dat er zowel behoefte is aan de mogelijkheid om informatie te verzenden (push-verkeer) als om informatie te kunnen opvragen (pull-verkeer). Er is geen uitwisselingspatroon dat voor alle samenwerkingsmodellen geschikt is, er zullen dus nu en in de toekomst meerdere informatiepatronen ondersteund dienen te worden. Voor directe uitwisseling tussen bekende zorgverleners (overdracht, gerichte consultatie) is push uitwisseling gewenst. Voor samenwerkingsvormen waarbij niet op voorhand bekend is welke zorgverleners en hierbij betrokken zijn en wanneer de informatie gebruikt wordt (inzage/seh, gezamenlijke behandeling) is gewenst dat er informatie beschikbaar is die door de zorgverlener op het gewenste tijdstip opgehaald kan worden. In die situaties is pull gewenst. Vervolgens is nagegaan welke opties voor infrastructuur momenteel beschikbaar zijn. Push: Directe overdracht Secure Secure Push: Indirecte overdracht met notificatie Postbus Postbus Push: Onder beheer van de patiënt Personal Health Record Personal Health Record Personal Health Record Pull: Opvragen uit een repository d.m.v. een registry XDS- Infrastructuur, LSP XDS- Infrastructuur, LSP Overdracht Consultatie Inzage 5

6 Bij de totstandkoming van het advies is als volgt te werk gegaan (2/2) De uitgangspunten waaraan een infrastructuur moet voldoen zijn in kaart gebracht : in een matrix zijn de infrastructuur opties gescoord tegen de uitgangspunten Secure- LSP XDS infra-structuur Postbus (niet IHE) Personal Health Record Kan eisen wet- en regelgeving implementeren en bewaken [2] Ondersteunt richtlijn EGiZ Ondersteunt NEN 7512 Ondersteunt alle typen zorggegevens Leverancier onafhankelijk [3] Schaalbaar [4] Gebaseerd op (inter)nationale standaarden Bewezen oplossingen en technologie Gedeelde informatie blijft binnen verantwoordelijkheidsgrenzen ziekenhuis [5] [5] [5] 6 [1]: Zie de bijlagen voor de volledige lijst met uitgangspunten. [2]: Voor de score op dit uitgangspunt is er van uit gegaan dat de afspraken tussen de communicatiepartners bepalen of wordt voldaan aan wet- en regelgeving. De score geeft aan of met de infrastructuur deze afspraken ook bewaakt resp. afgedwongen kunnen worden. [3]: Afhankelijk van encryptykey-server van de leverancier. [4]: Koppeling registry s en repository s nog geen schaalbare oplossing [5]: Eisen aan third party die de (tijdelijke) decentrale opslag host Voldoet volledige aan de uitgangspunten Kan aan de uitgangspunten voldoen, vraagt om procedure maatregelen Voldoet niet aan de uitgangspunten

7 Dit leidt tot de volgende adviezen van de werkgroep Advies aan de AcZie 1. Investeer in de (verdere) ontwikkeling van (regionale) netwerken 2. Baseer deze ontwikkeling op IHE-profielen: XDS voor pull, XDR voor push verkeer, XDW voor procesondersteuning van de uitwisseling 3. Laat elk academisch ziekenhuis een nadrukkelijke rol spelen in de voor hen relevante regio 4. Wees actief betrokken als academische ziekenhuizen bij de verdere ontwikkeling naar landelijke opschaling en sluit hiervoor aan bij de bestaande initiatieven van VZVZ, & de RSO s. Laat de RSO s hierin leidend zijn. 5. Implementeer secure op plaatsen waar nog geen op IHE gebaseerde oplossing beschikbaar is, of waar gezien de aard van het uitwisselingsproces, IHE een minder werkbare oplossing biedt 6. Voor het uitwisselen van grote bestanden en beelden kan indirecte overdracht via een postbussysteem een tussenoplossing bieden, zolang er geen XDS infrastructuur beschikbaar is; sluit hiervoor aan bij bestaande initiatieven 7. Eis contractueel van leveranciers van informatie overdrachtsapplicaties dat zij hun applicatie baseren of aanpassen op IHE standaarden. 8. Kijk naast het interoperabiliteits-niveau infrastructuur en techniek ook naar de bovenliggende interoperabiliteits-niveaus; hierbij dient de gebruiker niets te merken van de onderliggende infrastructuur (of systemen en informatie standaarden), maar dient de gebruiker ondersteund te worden bij de uitvoering in de oefening van het zorgproces. 7 interoperabiliteits-niveaus

8 Uitwerking samenwerkingsvormen en informatieuitwisselingspatronen

9 Samenwerkingsvormen* Communicatie richting Tweerichtings communicatie A: Overdracht: Het eenmalig overdragen van patiëntgegevens én behandelrelatie tussen twee zorgverleners B: Consultatie: Patiëntinformatie gaat eenmalig heen en weer B:Consultatie D:Gezamenlijke behandeling C: Inzage: De patiëntgegevens kunnen door meerdere zorgverleners worden geconsulteerd zonder dat de behandel relatie wordt overgedragen Eenrichting Communicatie D: Gezamenlijke behandeling: Meerdere zorgverleners werken samen in een gezamenlijk patiëntendossier A: Overdracht C:Inzage Eenmalig Meermalig 9 Patiënt Zorgverlener Hoe vaak vindt uitwisseling plaats * Dit advies houdt rekening met de volgende samenwerkingsvormen in de zorg: Overdracht, Inzien, Consultatie. Gezamenlijke behandeling wordt niet meegenomen in dit advies.

10 Informatie-uitwisselingspatronen Patiëntgegevens worden rechtstreeks van organisatie A naar organisatie B gestuurd (Push) A: Directe overdracht Patiëntgegevens worden door A in een tijdelijke opslag geplaatst. B ontvangt een notificatie en kan de gegevens aan de hand hiervan uit de opslag halen. (Push) B: Indirecte overdracht met notificatie Patiënt krijgt zijn gegevens mee van organisatie A (papier, PHR) en stelt ze zelf beschikbaar aan organisatie B (Push) C: Onder beheer van de patiënt Organisatie A geeft in een centrale registry aan te beschikken over bepaalde patiëntgegevens en geeft tevens aan waar die zijn te vinden. Organisatie B kan de gegevens a.d.h.v. de registry vinden en ophalen. (Pull) 10 D: Opvragen uit een repository a.d.h.v. een registry

11 Op basis van beheerbaarheid en werkbaarheid is bepaald welk uitwisselingspatroon past bij welke samenwerkingsvorm 1 De beheer- en werkbaarheid is sterk afhankelijk van het toegepaste patroon, die weer afhankelijk is van de use case en de hoeveelheid data Push Voor een snelle correspondentie is uitwisseling van patiëntgegevens via een centrale registory en een lokale repository voor een arts geen werkbare oplossing (te veel handelingen en gedoe ) terwijl een (in)directe overdracht snel en simpel werkt (zeker als dat geïntegreerd vanuit het EPD kan). Echter, een (in)directe overdracht is minder geschikt voor de uitwisseling van patiëntgegevens tussen meerdere zorgverleners Push vergt minder beheerlast voor de zorgverlener dan pull. Pull Voor de uitwisseling van patiëntgegevens tussen meerdere zorgverleners is het patroon met een centrale registry de enige werkbare oplossing, zeker als niet op voorhand bekend is welke zorgverleners betrokken zijn. Bij pull is patiëntconscent een groter vraagstuk. Bij push verkeer, bijvoorbeeld een verwijzing, mag er van worden uit gegaan dat de patiënt impliciet toestemming heeft gegeven. Hij/zij is immers akkoord met het feit die hij verwezen wordt. Het patroon met een centrale registry (Pull-verkeer) vergt meer beheerlast in verband met de privacywetgeving. Waarschijnlijk volstaat het straks niet meer om een vinkje te zetten voor de vraag: Patiënt consent aanwezig, maar moet er echt een (digitale) handtekening van de patiënt zijn; de patiënttoestemming moet aangetoond kunnen worden. Ook het beheer van autorisaties (wie mag waar bij) vraagt extra beheer. 11 Algemeen Het is van belang dat er inzage is in de benodigde en uitgevoerde processtappen. Het vraagt om procesondersteuning, met name in het geval van pull. Er is behoefte aan workflow ondersteuning zodat de betrokkenen weten welke activiteit er van hen verwacht wordt. 1 zie de bijlagen voor een uitgebreide samenvatting van de risicoanalyse per verschillende uitwisselingspatroon

12 Bruikbare informatie-uitwisselingspatronen per samenwerkingsvorm Mogelijke infrastructuur bij uitwisselingspatroon Push: Directe overdracht Push: Indirecte overdracht met notificatie Push: Onder beheer van de patiënt Pull: Opvragen uit een repository d.m.v. een registry Overdracht Consultatie Inzage 12 Legenda: Geschikte infrastructuur Minder geschikte infrastructuur Ongeschikte infrastructuur

13 Informatie-uitwisselingspatronen in relatie met infrastructuren Mogelijke infrastructuur bij uitwisselingspatroon Push: Directe overdracht Secure Secure Push: Indirecte overdracht met notificatie Postbus Postbus Push: Onder beheer van de patiënt Personal Health Record Personal Health Record Personal Health Record Pull: Opvragen uit een repository d.m.v. een registry XDS- Infrastructuur LSP XDSinfrastructuur LSP Overdracht Consultatie Inzage 13

14 Toetsing infrastructuren aan uitgangspunten [1] Secure LSP XDS infra- structuur Postbus (niet IHE) Personal Health Record Kan eisen wet- en regelgeving implementeren en bewaken [2] Ondersteunt richtlijn EGiZ Ondersteunt NEN 7512 Ondersteunt alle typen zorggegevens Leverancier onafhankelijk [3] Schaalbaar [4] Gebaseerd op (inter)nationale standaarden Bewezen oplossingen en technologie Gedeelde informatie blijft binnen verantwoordelijkheidsgrenzen ziekenhuis [5] [5] [5] Opmerkingen: [1]: Zie de bijlagen voor de volledige lijst met uitgangspunten. [2]: Voor de score op dit uitgangspunt is er van uit gegaan dat de afspraken tussen de communicatiepartners bepalen of wordt voldaan aan wet- en regelgeving. De score geeft aan of met de infrastructuur deze afspraken ook bewaakt resp. afgedwongen kunnen worden. [3]: Afhankelijk van encryptykey-server van de leverancier. [4]: Koppeling registry s en repository s nog geen schaalbare oplossing [5]: 14 Eisen aan third party die de (tijdelijke) decentrale opslag host Legenda: Voldoet volledige aan de uitgangspunten Kan aan de uitgangspunten voldoen, vraagt om procedure maatregelen Voldoet niet aan de uitgangspunten

15 Conclusie op grond van de toetsing Verschillende samenwerkingsvormen in de zorg, vragen verschillende informatie-uitwisselingspatronen (bv: push of pull) en infrastructuren die deze ondersteunen. Ook de eisen die, rekening houdend met de aard van het uitwisselingsproces, gesteld mogen worden aan de werkbaarheid (snel, eenvoudig) hebben invloed op de keuze van het overdrachtsmechanisme. Het infrastructuurprofiel IHE-XDS voldoet aan vrijwel alle uitgangspunten en kan hierdoor worden beschouwt als de meest toekomst vaste oplossing. Daarnaast bestaat er internationaal een prominente ontwikkeling op het gebied van IHE-profielen die (inter)nationaal groot draagvlak geniet. Binnen Nederland, via de regionale samenwerkingsverbanden (RSO s) is XDS de dominante infrastructuur. Naast de tevredenstellende score van het infrastructuurprofiel IHE-XDS bestaan er een aantal aspecten de aandacht verdieneen. Zo ontbreekt het aan een eenduidige invulling van de IHE-profielen Basic Patiënt Privacy Concent (IHE-BPPC) en Cross-Enterprise User Assertion (IHE-XUA). Daarnaast bestaat het vraagstuk hoe verschillende registries aan elkaar gekoppeld dienen te worden. Deze punten hinderen de landelijke opschaling van een XDS-infrastructuur. Verder is de werkbaarheid van XDS (in zijn huidige staat) beperkt, waardoor XDS minder geschikt is voor usecases waarin push de voorkeur heeft. Daarnaast bieden de huidige XDS-infrastructuren geen landelijke dekking zolang de registries (via het XCA-profiel) nog niet onderling gekoppeld zijn.. Een alternatief als secure mail en de indirecte overdracht via een postbus kan een tijdelijke oplossing bieden zolang er geen XDS infrastructuur beschikbaar is waar de betrokken partijen gebruik van kunnen maken. Dit geldt voor de situatie dat er nog geen XDS-infrastructuur operationeel is binnen de regio en de situatie dat de partijen niet tot dezelfde regio behoren. Bovendien verdient het gebruik van secure mail de voorkeur boven het gebruik van de XDSinfrastructuur in sommige use cases, zoals het aanvragen van aanvullend onderzoek. Het LSP biedt geen oplossing op de korte termijn voor de informatie uitwisselingsbehoefte zoals beelden, GOG enz. Echter zijn er vanuit het LSP belangrijke ervaringen opgedaan en concepten ontwikkeld die gebruikt kunnen worden voor verdere opschaling van XDS-infrastrcutuur 15 1 zie bijlagen voor toelichting op de verschillende IHE-profielen

16 Geadviseerde vervolgstappen

17 Geadviseerde vervolgstappen Participeer in een of meer initiatieven op het gebied van gegevensuitwissisling op basis van XDS, bijvoorbeeld POC voor Generieke Overdracht Gegevens, Landelijk Doorverwijzen van Alpe D huzes. Doe dit in samenwerking met NICTIZ, VZVZ, Alpe D Huzes en eventueel andere geïnteresseerde partijen. Werk (mee) aan landelijke afstemming op het gebied van de inrichting van de regionale infrastructuren zodat eenduidige werkwijzes ontstaan en regio s op elkaar kunnen aansluiten. Sluit hiervoor aan bij de bestaande initiatieven van VZVZ, en de RSO s. Laat de RSO s hierin leidend zijn. Werk (mee) aan verdere definiering van IHE-profielen welke complementair zijn aan het IHE-XDS infrastructuur profiel, zoals IHE- BPPC en IHE-XUA, zodat de schaalbaarheid binnen een XDS infrastructuur gewaarborgd wordt. Doe een pilot op basis van secure- . Onderzoek op basis van de uitgevoerde pilots wat de rol en impact is van leveranciers op de bestaande infrastructeren en wat de verwachte kosten zijn voor opschalen van een uitwisseling-infrastructuur. 17

18 Daarnaast wordt geadviseerd om tot landelijke afstemming te komen op de volgende punten B: Indirecte overdracht met notificatie Voor push: Beschikbaar komen van een landelijke zorgverlenersgids: Adressen en specialisem/specialisaties van de ontvangende zorgverleners. Die onafhankelijk van een aplicatie beherd en bruikbaar is. Adreslijsten tussenopslag Authenticatie methode aanmelder en opvrager (IHE-XDS-XUA profiel) Voor pull Patiënt concent (IHE-XDS-BPPC profiel) Registry (koppeling meerdere registry s) (IHE-XDS-XCA profiel) Authenticatie methode aanmelder en opvrager (IHE-XDS-XUA profiel) C: Opvragen uit een repository d.m.v. een registory 18

19 E A T E AcZie H.Maring@umcutrecht.nl Soulve Innovations Goeman Borgesiuslaan info@soulve.nu

20 Bijlagen I. Scope II. Uitwerking uitwisselingspatronen III. IHE integratie profielen IV. IHE profielen in relatie tot de gebruikte uitwisselingspatronen V. Uitgangspunten VI. Eisen voorkomend uit wet- en regelgeving VII. Samenvatting risico analyse

21 I. Om tot een advies te komen is de volgende scoping toegepast Uitwisseling van de volgende gegevenstypen vallen binnen de scope CCR patiëntgegevengs, bijvoorbeeld in de vorm van overdrachtsbrief en samenvatting patiëntdossier Diagnostische beelden De volgende instellingen vallen binnen de scope Alle ziekenhuizen De volgende security en privacy aspecten worden in acht genomen in dit advies Beveiligd transport Toetsen tegen richtlijnen Patiënt consent Identity management (identificatie, authenticatie, autorisatie) Auditing & logging De volgende use-cases vallen binnen de scope Overdracht Inzage Consultatie In dit advies ligt de focus op het interoperabiliteits-niveau infrastructuur en techniek Infrastructuur: Instellingen m.b.t. netwerk / firewalls Opstellen van protocol / software cummunicatieniveau (XDS) Data opslag Techniek: Interface naar infrastructuur Organisat ie (beleid) Zorgproces & Use Cases / Scenario s Informat ie (inhoud) Informat ie (vorm) Syst emen Infrast ruct uur en t echniek 21 Bron: Nictiz (2012) - Interoperabiliteit

22 II. Patiëntgegevens worden van organisatie A naar organisatie B gestuurd (Push) Dossier gegevens Organisatie A Organisatie B Kenmerken A moet weten wie B is A initieert de communicatie A stuurt, B ontvangt B is afhankelijk van A Voordelen Relatief eenvoudig te realiseren Beperkte beveiligingsrisico s Aandachtspunten Autorisatie zorgverleners Volledigheid van patiëntgegevens Minder geschikt voor samenwerking tussen meerdere zorgverleners Logging en auditing 22

23 II. Patiëntgegevens worden door A in een tijdelijke opslag geplaatst. B ontvangt een notificatie en kan de gegevens aan de hand hiervan uit de opslag halen. (Push) Notificatie Organisatie A Organisatie B Dossier gegevens Tijdelijke opslag Dossier gegevens Kenmerken Voordelen Aandachtspunten 23 A moet weten wie B is A initieert de communicatie A stuurt moet B op de hoogte stellen A stuurt, B haalt op B is afhankelijk van A B haalt info alleen op wanneer dat nodig is Logging van acties op de patiëntgegevens Autorisatie van zorgverleners Afhankelijkheid van derden voor tijdelijke opslag patiëntgegevens Minder geschikt voor samenwerking tussen meerdere zorgverleners

24 II. Patiënt krijgt zijn gegevens mee van organisatie A (papier, PHR) en stelt ze zelf beschikbaar aan organisatie B (Push) Dossier gegevens Dossier gegevens Organisatie A Patiënt Organisatie B Kenmerken A stelt patiëntgegevens ter beschikking aan de patiënt Patiënt slaat gegevens op in eigen PHR Patiëntgegevens blijven in PHR Patiënt geeft B toegang tot PHR Voordelen Patiënt houdt zelf regie over degene die toegang heeft tot de gegevens Aandachtspunten Tussenkomst van patiënt Volledigheid/integriteit van patiëntgegevens Accuraatheid van patiëntgegevens Afhankelijkheid van derden voor opslag patiëntgegevens 24

25 II. Organisatie A geeft in een centrale registry aan te beschikken over bepaalde patiëntgegevens en geeft tevens aan waar die zijn te vinden. Organisatie B kan de gegevens a.d.h.v. de registry vinden en ophalen. (Pull) publicatie Centrale Registry (index) opvragen Organisatie A Organisatie B Dossier gegevens Tijd onafhankelijke opslag (repository) Locatie bij organisatie of centraal Dossier gegevens Kenmerken Voordelen Aandachtspunten 25 A hoeft niet te weten wie B is A publiceert bericht (vult index) A plaatst patiëntgegevens in repository (lokaal of centraal) Patiëntgegevens blijven langdurig in repository B vraagt waar info beschikbaar is via index B haalt patiëntgegevens op uit repository B haalt info alleen op wanneer dat nodig is Goed inzetbaar wanneer meerdere (onbekende) hulpverleners toegang moeten hebben tot de gegevens Langdurige opslag van patiëntgegevens Logging van toegang tot patiëntgegevens Autorisatie van zorgverleners Patiënt consent Vaststellen van een behandelrelatie Afhankelijkheid van derden

26 III. IHE integratie profielen Algemeen IHE staat voor Integrating the Healthcare Enterprise. IHE is een internationaal samenwerkingsverband tussen gebruikers en leveranciers van ICT in de zorgsector. Het is opgericht in de Verenigde Staten en inmiddels actief in andere landen, waaronder Nederland. IHE Nederland is opgericht in Doelstelling van IHE is het oplossen van integratieproblemen bij software en medische apparatuur. IHE heeft als uitgangspunt geen nieuwe standaarden te ontwikkelen, maar beschikbare standaarden bij elkaar te brengen. Het vastleggen van welke standaarden in een specifieke context gebruikt worden, wordt gedaan in IHE integratieprofielen. Relatie met andere standaarden IHE ontwikkelt geen standaarden, maar verwijst in de integratieprofielen naar bestaande, breed geaccepteerde standaarden. Voorbeelden hiervan zijn HL7, SNOMED CT, LOINC en DICOM. Integratieprofielen Een integratieprofiel gaat over de uitwisseling van medische gegevens die nodig is om een specifieke klinische taak te kunnen bewerkstelligen. Daarnaast zijn er generieke technische integratieprofielen. Een profiel specificeert de informatie die tussen systemen moet worden uitgewisseld en de acties die systemen moeten uitvoeren wanneer ze de informatie sturen of ontvangen. Een integratieprofiel bevat gedetailleerde specificaties en beschrijft hoe de profielen geïmplementeerd kunnen worden. Het doet uitspraken over alle aspecten die een rol spelen, zoals beveiliging, authenticatie, protocollen enz. IHE Document Sharing Models Er wordt onderscheid gemaakt naar verschillende manieren van document uitwisseling. De toepassing is afhankelijk van de gebruikte use case. Hiervoor zijn afzonderlijke integratieprofielen ontwikkeld: XDM: document uitwisseling, zonder eisen aan transport medium XDR: document uitwisseling eisen aan transportmedium en bericht structuur XDS: infrastructuur met opslag en index (zie uitwerking volgende dia) XDS-XCA: infrastructuur om XDS infrastructuren aan elkaar te koppelen 26 Bronnen: Interoperability for dummies. IHE-USA. Samarth, A ICT-Standaarden in de Zorg. Nictiz Health Information Exchange: Enabling Document Sharing Using IHE Profiles. Witting, K.; Moehrke, J.

27 III. IHE integratie profielen XDS XDS XDS staat voor Cross Enterprise Document Sharing. XDS is een van de technische profielen van IHE. Het IHE-XDS profiel bestaat sinds 2003 en heeft als doel om documenten tussen zorginstellingen met elkaar te delen. Zo kunnen CT-onderzoeken, MRI-scans, labuitslagen, overdrachtsdocumenten en verwijsbrieven tussen zorginstellingen gedeeld worden. Werking van XDS-profiel Feitelijk is een XDS-netwerk een generieke oplossing om documenten uit te wisselen. Het IHE-XDS profiel kan veel bestandsformaten uitwisselen zoals PDF, Word, JPG, HL7-CDA en DICOM. Binnen Nederland is het XDS-profiel voornamelijk bekend van digitale beelduitwisseling, Samenwerkende instellingen die afspraken maken over de uitwisseling van medische gegevens via een XDS-netwerk heet een affinity domain. Binnen een affinity domain zijn vier systeemrollen: instellingen die gegevens aanmelden, die heten document sources ; instellingen die gegevens opvragen, die heten document consumers ; een gegevensopslag, dit heet een repository ; een index, dit is een register met daarin de verwijzingen naar de plaats waar gegevens zijn opgeslagen, dit heet een registry. Als een zorgverlener informatie beschikbaar wil stellen slaat hij die op in de repository en meldt deze gegevens aan in de registry. De raadplegende zorgverlener zoekt op de registry naar beschikbare relevante informatie van een patiënt en krijgt van de registry een verwijzing in welke instelling de informatie zich bevindt. De informatie haalt hij vervolgens zelf bij deze repository op. Medische gegevens zijn dus niet centraal opgeslagen maar blijven bij de bron. Om het zoeken op de registry te faciliteren bevat de registry een aantal gegevens over de beschikbare informatie zoals de patiëntidentificatie, type document en instelling. De basisfunctionaliteit van een XDS-profiel kan echter niet toegepast worden zonder gebruik te maken van aanvullende IHE profielen. Een paar van deze profielen zijn: IHE-BPPC: dit profiel heeft als doel om toestemmingsprofielen van de patiënt te definiëren. IHE-CT: om tijdsynchronisatie tussen systemen te borgen. IHE-ATNA: om de logging te implementeren. IHE-XCA: om meerdere affinity domains aan elkaar te koppelen. IHE-XUA: authenticatie van gebruikers Om een XDS-netwerk volledig in te richten zijn dus meerdere IHE-profielen nodig. 27

28 III. IHE integratie profielen XDW Het XDW profiel stelt gebruikers vanuit verschillende zorgverleners organisaties in staat de verschillende stappen in het zorgproces te ondersteunen. Het biedt de mogelijkheid voor workflow ondersteuning. Het bouwt voort op andere IHE profielen rond document uitwisseling zoals het XDS profiel. Het biedt een generieke infrastructuur waar verschillende vormen van workflow ondersteuning op aan kunnen sluiten. 28

29 IV. Het Cross-Enterprise Document Reliable Interchange (XDR) maakt een directe, point to point, uitwisseling van patiëntgegevens mogelijk (Push) Dossier gegevens Organisatie A Organisatie B Of Notificatie Organisatie A Organisatie B Dossier gegevens Tijdelijke opslag Dossier gegevens Het IHE-XDR profiel kan gebruikt worden voor het versuren van patient gegevens i.c.m. bestaande diensten zoals secure of een cloud-based oplossing 29 Bron: Health Information Exchange: Enabling Document Sharing Using IHE Profiles. Witting, K.; Moehrke, J.

30 IV. Het Cross-Enterprise Document Sharing (XDS) profiel maakt een gecentraliseerde uitwissling, via een pull-mechanisme, van patiëntgegevens mogelijk XDS Document (Metadata): Type Patiënt ID Auteur Zorginstelling Datum Etc. Registry 2 3 Organisatie B 4 Organisatie A 1 Repository 1. Organisatie A upload patiëntgegevens naar een tijdonfankelijke opslagplaats (repository) 2. De repository registreert de metadata en een link naar de documentatie in de registory 3. Organisatie B zoekt d.m.v. specifieke informatie naar patiëntgegevens in het registry (patiëntconcent is nodig om zoekresultaten te kunnen vinden) 4. Via de repository wordt organisatie B doorverwezen naar de repository waar de patiëntgegevens worden verkregen 30 Bron: Health Information Exchange: Enabling Document Sharing Using IHE Profiles. Witting, K.; Moehrke, J.

31 IV. Verder moet er invullen worden gegeven aan de volgende profielen om uitwisseling van gegevens via het IHE-XDS profiel mogelijk te maken Afkorting (PIX) Patiënt Identifier Profiel Cross Referencing, Maakt referenties van Beschrijving dezelfde patiënt tussen verschillende systemen mogelijk. PIX Patiënt Identifier Cross Referencing Maakt referenties van dezelfde patiënt tussen verschillende systemen Audit Trail and Node Authentication (ATNA): Waarborgt de vertrouwelijkheid, mogelijk. intergriteit van patiëntgegevens waardborgt via een ATNA gebruikers authenticator Audit Trail en connectie and Node Authentication authenticator. Daarnaast Waarborgt waarborgt de vertrouwelijkheid, het ATNA-profiel intergriteit ook de toerekenbaarheid van patiëntgegevens via een audit trail waardborgt via een gebruikers authenticator en connectie authenticator. Daarnaast waarborgt het ATNA-profiel ook de toerekenbaarheid via een audit trail Notification of Document Availability (NAV). Definieert een mechanisme voor point-to-point notificaties tussen systemen binnenin een, of tussen verschillende, XDS-affnity domeinen. NAV Consistent Time (CT). Notification Waarborgt of synchronisatie Document Availability van tijdstippen Definieert tussen verschillende een mechanisme tijdzones voor point-to-point notificaties tussen systemen binnenin een, of tussen verschillende, XDS-affnity domeinen. Basic Patiënt Privacy Consents (BPPC) CT Consistent Time Waarborgt synchronisatie van tijdstippen tussen verschillende tijdzones (Cross-)Enterprise User Assertion (X/E UA) BPPC Basic Patiënt Privacy Consents Waarborgt de verschillende toestemmingsprofielen van de patiënt XUA of EUA (Cross-)Enterprise User Assertion Waarborgt de autorisatie van een geauthenticeerde zorgverlener XCA Cross-Community Access Overkoepelend profiel om meerdere XDS-affinity domains met elkaar te verbinden 31

32 IV. Het Cross-Enterprise Document Workflow (XDW) profiel stelt zorgverleners in staat om de status van patiëntgegevens te volgen tijdens een order 1 2 Zorgverlener A Organisatie B 4 3 XDS-omgeving 1. Zorgverlener A initieeert een verwijzing en upload de patientgegevens naar een XDS omgeving 2. Organisatie B accepteert de verwijzing en haalt de patiëntgegevens van de XDS omgeving 3. Organisatie B upload de toegevoegde patiëntgegevens in de XDS omgeving 4. Zorgverlener A ontvangt een notificatie dat de patiëntgegevens zijn aangevuld en kan deze inzien 32 Bron: Health Information Exchange: Cross-Enterprise Document Workflow (XDW). Zalunardo, L.; Cocchiglia, A.

33 V. Om tot de gewenste infrastructuur voor de uitwisseling van generieke overdrachtsgegevens tussen ziekenhuizen in Nederland te komen, zijn de volgende 10 uitgangspunten opgesteld 1. De oplossing moet in staat zijn om de eisen die voortkomen uit wet- en regelgeving, te implementeren en te bewaken. 2. De gedragscode EGiZ (Elektronische Gegevensuitwisseling in de Zorg) is leidend voor de uitwerking en inrichting van privacy gerelateerde zaken. 3. Met de gekozen infrastructuur kan worden voldaan aan de norm voor vertrouwde gegevensuitwisseling in de zorg, de NEN 7512:2005 uitgaande van het vertrouwelijkheidrisico Hoog. 4. De gekozen infrastructuur is generiek en kan gebruikt worden voor alle uit te wisselen medische gegevens, onafhankelijk van format en omvang (documenten, beelden, multimediabestanden etc.). 5. De gekozen infrastructuur leidt niet tot afhankelijkheid van een leverancier. 6. De gekozen infrastructuur moet schaalbaar zijn, zowel wat betreft het volume van het aantal deelnemers en uit te wisselen gegevens als wat betreft het aantal use cases en het aansluiten van andere gebruikersgroepen (bijvoorbeeld: ook 1 e en 3 e lijn en andere regio s). 7. De gekozen infrastructuur is gebaseerd op (inter-)nationale standaarden voor gegevensuitwisseling in de zorg voor zowel de inhoud van de berichten (CDA, DICOM e.a.) als de toegepaste techniek en protocollen (HL7, IHE e.d.), zoals deze momenteel wordt toegepast in Nederland. 8. De gekozen infrastructuur maakt gebruik van bewezen oplossingen en technologie en wordt breed gebruikt binnen Nederland 9. Alle gedeelde informatie blijft in de bronsystemen beschikbaar en het is voor de gegevensuitwisseling niet noodzakelijk deze (redundant) in een centrale repository vast te leggen. Alle gedeelde informatie blijft binnen de verantwoordelijkheidsgrenzen van het ziekenhuis. 10. Vanuit het oogpunt van werkbaarheid, moeten de te nemen (privacy en security) maatregelen- en de door de gebruiker uit te voeren acties, in verhouding staan tot het doel van de communicatie en de daarmee samenhangende risico s. 33

34 VI. Eisen voortkomend uit de weg- en regelgeving Voor de verwerking en uitwisseling van gegevens via Pull-verkeer, is vooraf uitdrukkelijke toestemming van de patiënt (patient consent) vereist. De toestemming van de patiënt moet vastgelegd en geraadpleegd kunnen worden. Raadplegen van patiëntgegevens is alleen toegestaan voor zorgverleners met een behandelrelatie en zonodig na uitdrukkelijke toestemming van de patiënt. Toegang tot de infrastructuur is uitsluitend toegestaan voor geauthenticeerde en geautoriseerde personen. Logging op alle (inzage) acties op patiëntgegevens via de infrastuctuur, vindt plaats volgens NEN (Nader uit te werken). Hierbij wordt voor iedere transactie tenminste de volgende gegevens vastgelegd: de uitgevoerde actie, datum en tijd, identiteit van de patiënt, identiteit van de zorgverlener, identiteit van de zorgaanbieder. De patiënt heeft recht op inzage van de loggegevens van wie toegang is verleend tot zijn gegevens en wie daar gebruik van hebben gemaakt. Vertrouwelijke gegevens mogen alleen opgeslagen worden binnen de verantwoordelijkheidsgrenzen van het ziekenhuis. Zie de gedragscode EGiZ voor een definitie van gegevensuitwisseling op basis van Push en Pull verkeer. 34

35 VII Samenvatting risicoanalyse Directe overdracht Indirecte overdracht met notificatie Opvragen uit een repository d.m.v. een registory Onder beheer van de patiënt Vertrouwelijkheid Beveiligde verbinding tussen organisaties vereist Beveiligde verbinding tussen organisaties én tijdelijke opslag vereist Beveiligde verbinding tussen organisaties, index én repository vereist Afhankelijkehid van derden voor oplsag van patiëntgegevens Toerekenbaarheid Procedureel borgen, bijvoorbeeld door het invoeren van een digitale handtekening Procedureel borgen, bijvoorbeeld door het invoeren van een digitale handtekening Heldere afspraken over logging zijn vereist om onweerlegbaarheid veilig te stellen Procedureel borgen, door vast te leggen wanneer patiëntgegevens naar of van de patiënt zijn overgedrgen Authenticiteit Autorisatie Procedureel borgen,door bijvoorbeeld UZI-pas te gebruiken Inrichten autorisatieprocedure aangevuld met jaarlijkse controle of de juiste mensen toegang hebben tot de juiste gegevens Procedureel borgen,door bijvoorbeeld UZI-pas te gebruiken Inrichten autorisatieprocedure in overleg met derden aangevuld met jaarlijkse controle of de juiste mensen toegang hebben Procedureel borgen,door bijvoorbeeld UZI-pas te gebruiken Inrichten autorisatieprocedure in overleg met derden aangevuld met jaarlijkse controle of de juiste mensen toegang hebben Procedureel borgen, bijvoorbeeld door de patiëntgegevens te koppelen aan het BSN van de patiënt Patiënt houdt zelf regie over degene die toegang heeft tot de gegevens Gegevens integriteit Zorg voor voldoende authenticeiten autorisatie maatregelen en waar mogelijk 4-ogen principe hanteren, plus technische maatregelen in de vorm van standaardprotocollen Zorg voor voldoende authenticeiten autorisatie maatregelen en waar mogelijk 4-ogen principe hanteren, plus technische maatregelen in de vorm van standaardprotocollen Zorg voor voldoende authenticeiten autorisatie maatregelen en waar mogelijk 4-ogen principe hanteren, plus technische maatregelen in de vorm van standaardprotocollen Zorg voor voldoende authenticeiten autorisatie maatregelen en waar mogelijk 4-ogen principe hanteren, plus technische maatregelen in de vorm van standaardprotocollen Beschikbaarheid 35 Technische voorzorgsmaateregelen treffen, zoals het gebruik van een virusscanners en firewalls, om een uptime van 99,9% te garanderen Technische voorzorgsmaateregelen treffen, zoals het gebruik van een virusscanners en firewalls, om een uptime van 99,9% te garanderen Technische voorzorgsmaateregelen treffen, zoals het gebruik van een virusscanners en firewalls, om een uptime van 99,9% te garanderen Technische voorzorgsmaateregelen treffen, zoals het gebruik van een virusscanners en firewalls, om een uptime van 99,9% te garanderen