Advies infrastructuur voor uitwisseling van de generieke overdrachtsgegevens in Nederland

Advies infrastructuur voor uitwisseling van de generieke overdrachtsgegevens in Nederland

Inhoud

1. 2. 3.

Aanleiding en Samenvatting Uitwerking samenwerkingsvormen en informatieuitwisselingspatronen Geadviseerde vervolgstappen

•

Bijlagen

Aanleiding en Samenvatting

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 infrastructuur1 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

1Onder

infrastructuur wordt in dit verband verstaan: aspecten als netwerk connectiviteit, authenticatie/autorisatie/logging, patiëntrechten, adresboeken, versturen of opvragen (push versus pull) en beheer.

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

Push:

Indirecte overdracht met notificatie

Push:

Pull:

Onder beheer van de patiënt Opvragen uit een repository d.m.v. een registry

Secure email

Secure email

Postbus

Postbus

Personal Health Record

Personal Health Record • XDSInfrastructuur, • LSP

Overdracht

5

Consultatie

Personal Health Record • XDSInfrastructuur, • LSP

Inzage

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-email

LSP

XDS infra-structuur

Postbus (niet IHE)


Kan eisen weten regelgeving implementeren en bewaken [2] Ondersteunt richtlijn EGiZ Ondersteunt NEN 7512 Ondersteunt alle typen zorggegevens Leverancier onafhankelijk

[3] [4]

Schaalbaar Gebaseerd op (inter)nationale standaarden Bewezen oplossingen en technologie Gedeelde informatie blijft binnen verantwoordelijkheidsgrenzen ziekenhuis

6

[5]

[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 weten 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

[5]

• • •

[5]

Voldoet volledige aan de uitgangspunten Kan aan de uitgangspunten voldoen, vraagt om procedure maatregelen Voldoet niet aan de uitgangspunten

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 e-mail 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

Uitwerking samenwerkingsvormen en informatieuitwisselingspatronen

Samenwerkingsvormen*

Communicatie richting

A: Overdracht: Het eenmalig overdragen van patiëntgegevens én behandelrelatie tussen twee zorgverleners

Tweerichtings communicatie

B: Consultatie: Patiëntinformatie gaat eenmalig heen en weer B:Consultatie

D:Gezamenlijke behandeling

Eenrichting Communicatie

C: Inzage: De patiëntgegevens kunnen door meerdere zorgverleners worden geconsulteerd zonder dat de behandel relatie wordt overgedragen D: Gezamenlijke behandeling: Meerdere zorgverleners werken samen in een gezamenlijk patiëntendossier

A: Overdracht

Eenmalig

C:Inzage

Meermalig

Hoe vaak vindt uitwisseling plaats Patiënt

9

Zorgverlener

* Dit advies houdt rekening met de volgende samenwerkingsvormen in de zorg: Overdracht, Inzien, Consultatie. Gezamenlijke behandeling wordt niet meegenomen in dit advies.

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) D: Opvragen uit een repository a.d.h.v. een registry

10

Op basis van beheerbaarheid en werkbaarheid is bepaald welk uitwisselingspatroon past bij welke samenwerkingsvorm1 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.

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.

11

1zie

de bijlagen voor een uitgebreide samenvatting van de risicoanalyse per verschillende uitwisselingspatroon

Bruikbare informatie-uitwisselingspatronen per samenwerkingsvorm

Mogelijke infrastructuur bij uitwisselingspatroon Push:

Directe overdracht

Push:


Push:

Onder beheer van de patiënt

Pull:

Opvragen uit een repository d.m.v. een registry

Overdracht

Consultatie

Inzage Legenda:

12

Geschikte infrastructuur Minder geschikte infrastructuur Ongeschikte infrastructuur

Informatie-uitwisselingspatronen in relatie met infrastructuren

Mogelijke infrastructuur bij uitwisselingspatroon Push:

Directe overdracht

Push:


Push:


Pull:

Opvragen uit een repository d.m.v. een registry

Secure email

Secure email

Postbus

Postbus



• •

Overdracht

13

XDSInfrastructuur LSP

Consultatie


• •

XDSinfrastructuur LSP

Inzage

Toetsing infrastructuren aan uitgangspunten[1] Secureemail

LSP

XDS infrastructuur

Postbus (niet IHE)


Kan eisen weten 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:

Legenda:

[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 weten 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

• •

14

•

Voldoet volledige aan de uitgangspunten Kan aan de uitgangspunten voldoen, vraagt om procedure maatregelen Voldoet niet aan de uitgangspunten

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

1zie

bijlagen voor toelichting op de verschillende IHE-profielen

Geadviseerde vervolgstappen

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 IHEBPPC en IHE-XUA, zodat de schaalbaarheid binnen een XDS infrastructuur gewaarborgd wordt.

Doe een pilot op basis van secure-email.

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

Daarnaast wordt geadviseerd om tot landelijke afstemming te komen op de volgende punten

Voor push:

B:

• 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:

18

Opvragen uit een repository d.m.v. een

registory

AcZie E [email protected] Soulve Innovations A Goeman Borgesiuslaan 77 T 030-7531486 E [email protected]

I. II. III. IV.

Bijlagen

Scope Uitwerking uitwisselingspatronen IHE integratie profielen IHE profielen in relatie tot de gebruikte uitwisselingspatronen V. Uitgangspunten VI. Eisen voorkomend uit weten regelgeving VII. Samenvatting risico analyse

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 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 instellingen vallen binnen de scope • Alle ziekenhuizen

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 Inf ormat ie (inhoud) Inf ormat ie (vorm) Syst emen Inf rast ruct uur en t echniek

Bron: Nictiz (2012) - Interoperabiliteit

21

II.

Patiëntgegevens worden van organisatie A naar organisatie B gestuurd (Push)

Dossier gegevens Organisatie A

Organisatie B

Kenmerken

Voordelen

Aandachtspunten

• • • •

•

• •

A moet weten wie B is A initieert de communicatie A stuurt, B ontvangt B is afhankelijk van A

•

Relatief eenvoudig te realiseren Beperkte beveiligingsrisico’s

• •

22

Autorisatie zorgverleners Volledigheid van patiëntgegevens Minder geschikt voor samenwerking tussen meerdere zorgverleners Logging en auditing

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

Kenmerken

Voordelen

Aandachtspunten

• • •

•

•

• •

23

Dossier gegevens

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

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

Organisatie B

Kenmerken

Voordelen

Aandachtspunten

•

•

• •

• • •

24

Patiënt

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

Patiënt houdt zelf regie over degene die toegang heeft tot de gegevens

• •

Tussenkomst van patiënt Volledigheid/integriteit van patiëntgegevens Accuraatheid van patiëntgegevens Afhankelijkheid van derden voor opslag patiëntgegevens

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)

Centrale Registry (index)

publicatie

opvragen

Organisatie A

Organisatie B Dossier gegevens

Tijd onafhankelijke opslag (repository)

Dossier gegevens

Locatie bij organisatie of centraal

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

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 2004. 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

Bronnen:

26

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.

III.


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

III.


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

XDW

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 email of een cloud-based oplossing

29

Bron: Health Information Exchange: Enabling Document Sharing Using IHE Profiles. Witting, K.; Moehrke, J.

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.

3

Organisatie B

Registry

2 4

Organisatie A

1. 2. 3. 4.

30

1

Repository

Organisatie A upload patiëntgegevens naar een tijdonfankelijke opslagplaats (repository) De repository registreert de metadata en een link naar de documentatie in de registory Organisatie B zoekt d.m.v. specifieke informatie naar patiëntgegevens in het registry (patiëntconcent is nodig om zoekresultaten te kunnen vinden) Via de repository wordt organisatie B doorverwezen naar de repository waar de patiëntgegevens worden verkregen

Bron: Health Information Exchange: Enabling Document Sharing Using IHE Profiles. Witting, K.; Moehrke, J.

IV.

Verder moet er invullen worden gegeven aan de volgende profielen om uitwisseling van gegevens via het IHE-XDS profiel mogelijk te maken

(PIX) Patiënt Identifier Cross Referencing, Maakt referenties van dezelfde patiënt tussen verschillende systemen mogelijk. Afkorting Profiel Beschrijving PIX

Patiënt Identifier Cross Referencing

Maakt referenties van dezelfde patiënt tussen verschillende systemen mogelijk. Audit Trail and Node Authentication (ATNA): Waarborgt de vertrouwelijkheid, intergriteit van patiëntgegevens waardborgt via een ‘gebruikers authenticator’ en ‘connectie authenticator’. Daarnaast waarborgt het ATNA-profiel intergriteit ook de toerekenbaarheid via een ATNA Audit Trail and Node Authentication Waarborgt de vertrouwelijkheid, van patiëntgegevens ‘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 Notification Document Availability Definieert een mechanisme voor point-to-point notificaties tussen Consistent Time (CT). Waarborgtofsynchronisatie van tijdstippen tussen verschillende tijdzones systemen binnenin een, of tussen verschillende, XDS-affnity domeinen.

Basic Patiënt Privacy Consents (BPPC) (Cross-)Enterprise User Assertion (X/E UA)

CT

Consistent Time

Waarborgt synchronisatie van tijdstippen tussen verschillende tijdzones

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

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

Organisatie B

Zorgverlener A

4

3 XDS-omgeving

1. 2. 3. 4.

32

Zorgverlener A initieeert een verwijzing en upload de patientgegevens naar een XDS omgeving Organisatie B accepteert de verwijzing en haalt de patiëntgegevens van de XDS omgeving Organisatie B upload de toegevoegde patiëntgegevens in de XDS omgeving Zorgverlener A ontvangt een notificatie dat de patiëntgegevens zijn aangevuld en kan deze inzien

Bron: Health Information Exchange: Cross-Enterprise Document Workflow (XDW). Zalunardo, L.; Cocchiglia, A.

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 weten 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 1e en 3e 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

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 7513. (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

VII

Samenvatting risicoanalyse Directe overdracht


Opvragen uit een repository d.m.v. een registory


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

Procedureel borgen ,door bijvoorbeeld UZI-pas te gebruiken



Procedureel borgen, bijvoorbeeld door de patiëntgegevens te koppelen aan het BSN van de patiënt

Autorisatie

Inrichten autorisatieprocedure aangevuld met jaarlijkse controle of de juiste mensen toegang hebben tot de juiste gegevens

Inrichten autorisatieprocedure in overleg met derden aangevuld met jaarlijkse controle of de juiste mensen toegang hebben

Inrichten autorisatieprocedure in overleg met derden aangevuld met jaarlijkse controle of de juiste mensen toegang hebben

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




Technische voorzorgsmaateregelen treffen, zoals het gebruik van een virusscanners en firewalls, om een uptime van 99,9% te garanderen




Beschikbaarheid

35

Advies infrastructuur voor uitwisseling van de generieke overdrachtsgegevens in Nederland

Recommend Documents