Vragen en uitleg bij implementatie van een XDS infrastructuur April 2014

Transcriptie

1 Vragen en uitleg bij implementatie van een XDS infrastructuur April 2014

2 Voor wie is dit document bedoeld? XDS is een op standaarden gebaseerd profiel dat beheerd wordt door de internationale organisatie IHE. Dit profiel kan ingezet worden bij het delen van medische informatie tussen zorginstellingen maar vereist afstemming en organisatie op vele niveaus. Dit document vormt een handreiking voor de implementatie van XDS dat zich richt op twee typen doelgroepen: Toekomstige gebruikers van XDS infrastructuren (bestuurders, zorgmanagers, informatiemanagers, IT afdelingen, etc.) Betrokkenen bij de facilitatie van XDS infrastructuren (regionale samenwerkingsorganisaties, adviesbureaus, expertisecentra voor standaardisatie, etc.) Dit document bevat een inventarisatie, geen totaal-opsomming. Sommige onderdelen zijn ook toepasbaar bij het realiseren van andere oplossingen dan die gebaseerd op XDS; het document is hier echter niet primair voor bedoeld. 2

3 Realisatie van een XDS infrastructuur vereist organisatie en techniek; dit document gaat over technische inrichting en -realisatie BUITEN SCOPE (zie bijlage) A. ORGANISATIE Type informatie-uitwisseling Procesbeschrijvingen Vastleggen afspraken in convenant Keuze en afspraken leverancier Kostenverdeling partners Communicatie en support B. ONDERHOUD Beleid omtrent misbruik, Consequenties Bewaartijd van informatie BINNEN SCOPE C. TECHNISCHE INRICHTING Identificatie Authenticatie Autorisatie Logging D. TECHNISCHE REALISATIE Netwerk & Firewall Koppelingen Back-up & herstel, onderhoud Beveiligingsbeleid Informatieve plicht, inrichting patiëntrechten Hosting XDS omgeving, serverlocatie 3 Zie voor onderdeel A: Organisatie de presentatie Oplossingen voor uitwisseling van medische gegevens

4 1. Algemene introductie XDS 2. Technische inrichting Identificatie Authenticatie Autorisatie Logging 3. Technische realisatie Netwerk & Firewall Koppelingen Backup & herstel, onderhoud Beveiligingsbeleid Informatieve plicht + inrichting patiëntrechten Hosting XDS omgeving, serverlocatie 4. Bijlagen Onderdelen buiten scope van presentatie Lijst met producten die een project zou moeten opleveren Lijst met risico s Grof stappenplan Overzicht projectstakeholders Ervaring met XDS Landelijke ontwikkelingen XDS Relevante profielen

5 Dit document stelt vragen, geeft toelichting en noemt IHE profielen relevant bij een XDS implementatie Vragen die relevant zijn voor implementatie Toelichting of uitleg Relevante IHE profielen Praktische informatie 5

6 Algemene introductie XDS

7 In een XDS affinity domain wordt op onderstaande manier gecommuniceerd Document 1 Document 4 Document Source Repository* 1 consumer A * 1 2 B Document aanmelden 3 Document opvragen Document Registry 7 * 1 : Een repository is optioneel

8 De toegangsketen voor een affinity domain bestaat uit vier elementen (1/2) 1. Identificatie: identificatie is het startpunt van iedere handeling via een XDS-netwerk. De vervolgstappen in de toegangsketen kunnen zonder identificatie niet worden gezet [IHE profielen: PIX (voor patiëntidentificatie), UZI-pas of UZI servercertificaat (voor zorgverlener identificatie)] 2. Authenticatie: als de identiteit is vastgesteld dient deze te worden geverifieerd. Anders gezegd dient de zorgaanbieder te bewijzen dat hij is wie hij zegt te zijn. Deze tweede stap wordt ook wel aangeduid als authenticatie. [IHE profielen: ATNA, XUA] 8

9 De toegangsketen voor een affinity domain bestaat uit vier elementen (2/2) 3. Autorisatie: nadat identificatie en authenticatie hebben plaatsgevonden, wordt het autorisatieproces doorlopen. Autorisatie heeft betrekking op de vraag welke gegevens de zorgaanbieder mag inzien en welke gebruikshandelingen hij mag verrichten. Hiervoor is een behandelrelatie, als voorwaarde van de autorisatie, noodzakelijk. [IHE profielen: BPPC, XUA, XUA++] 4. Logging: het vierde element van de toegangsketen betreft de registratie van de toegang en het gebruik van patiëntgegevens. Dit element wordt ook wel aangeduid als auditlogging. Door middel van logging kan worden gecontroleerd of inzage rechtmatig heeft plaatsgevonden. Logging dient zowel periodiek als na incidenten getoetst te worden; dit vereist een loggingsbeleid en beheer [IHE profielen: ATNA] 9

10 Autorisatie 2 van een zorgaanbieder om patiëntgegevens te raadplegen is gebonden aan enkele aspecten Aspect Behandelrelatie Toelichting De behandelrelatie van de patiënt en de zorgverlener. Deze behandelrelatie kan worden getoetst volgens de gedragscode Elektronische Gegevensuitwisseling in de Zorg (EGiZ) Toestemming patiënt Autorisatieprotocol / -matrix De patiënt moet toestemming verlenen aan de zorgverlener(s) om zijn medische gegevens te delen. Zodra een patiënt zijn toestemmingsprofiel wijzigt, bijvoorbeeld van een uitdrukkelijke toestemming naar een generiek bezwaar, dan wordt het oude toestemmingsprofiel verwijderd of overruled. (Zie EGiZ) In een autorisatieprotocol wordt voor ider type beroepsoefenaar aan de hand van de BIG-rolcodes vastgelegd welke gebruikshandelingen hij mag verrichten. Welke beroepsoefenaar toegang krijgt, wordt voor idere zorgtoepassing afzonderlijk bepaald door een autorisatiecommssie waarin relevante beroepsgroepen en belangenorganisatie zijn vertegenwoordigd 2 Autorisatie is het verlenen van bevoegdheden tot het verrichten van bepaalde handelingen 10

11 C. Inrichting 1. Identificatie 2. Authenticatie 3. Autorisatie 4. Logging D. Technische realisatie 1. Identificatie

12 Implementatievragen bij identificatie Patiënt Op basis waarvan wordt de patiënt geïdentificeerd / geauthentiseerd?(gebruikersnaam + wachtwoord, sms-verificatie, DIGID, face-to-face controle, combinatie, etc. *1 ) Hoe te handelen als de identificatie parameter niet bekend is? (sommige bronsystemen registreren alleen het lokale patiëntennummer, dit vereist een vertaling naar bijv. BSN, geboortedatum, etc.) Op basis van welke parameters kunnen patiënten d.m.v. cross-referencing uit betrokken bronsystemen worden gekoppeld? (PIX profiel, XCPD (zoeken) en MPI (master patient indexing) Zorgverlener Op basis waarvan wordt de zorgverlener geïdentificeerd? (UZI-pas + pincode, Digipass, Naam, BIG-code, IP-adres, combinatie, anders) 12 Bronnen: * 1: Handreiking patiëntauthenticatie (Nictiz), Patiënt identificatie en authenticatie voor zorgportalen (Nictiz)

13 Een XDS registry bevat velden voor de volgende patiëntgegevens Gegevens registry* Naam Adres Woonplaats Geboortedatum Ziekenhuis waar de gegevens staan BSN Meta data (aanmelder, evnt. modaliteit, aantal beelden, type verrichting) Toestemming vooraf plus doel (BPPC) Gegevens uit verleden van de informed consent (afzonderlijke toestemming per gegeven) Logging (ATNA) *Bron: KA11004C Eindrapportage e-radiologie Convenant privacy en security v1.0 (Nictiz, EZDA) 13

14 IHE Profiel patiëntidentificatie: PIX The PIX profile supports the cross-referencing of patient identifiers from multiple Patient Identifier Domains. These cross-referenced patient identifiers can then be used by identity 740 consumer systems to correlate information about a single patient from sources that know the patient by different identifiers. This allows a clinician to have more complete view of the patient information. 14 Conclusie: instellingen kunnen voorafgaand aan een XDS implementatie afspraken maken over hoe kruislings refereren van patiënten in zijn werk gaat en op basis van welke parameters

15 C. Inrichting 1. Identificatie 2. Authenticatie 3. Autorisatie 4. Logging D. Technische realisatie 2. Authenticatie

16 Implementatievragen bij authenticatie Hoe wordt zorgverlener-authenticatie gerealiseerd? (UZI-pas bevat certificaat met elektronische handtekening van het UZI-register) Wat als niet iedere zorgverlener over een UZI-pas beschikt? (Gebruik van lokale passen of authenticatiemiddelen, gebruik van UZI nummer in applicatie, authenticatie d.m.v. Palgacode of PRN code, etc.) Kan Single-sign-on (SSO) gerealiseerd worden? Hoe? (Bijvoorbeeld: Clinical Context Object Workgroup of CCOW) Hoe te handelen bij zorgverleners zonder BIG/AGB? Is er een uniform authenticatiemiddel nodig? Worden afspraken gemaakt over de randvoorwaarden rondom het authenticatiemiddel, aan welke minimale eisen moet dit voldoen? 16 Voor relevante documentatie over de inrichting van authenticatie voor het LSP (ten dele toepasbaar op XDS) wordt verwezen naar: Ontwerp Authenticatie (Nictiz, 2011)

17 De volgende authenticatiemethoden 1 zijn bekend Methode Werking Toepassing Knelpunten UZI-certificaat X.509 protocol: Het UZI-register levert het UZIcertificaat met daarin de publieke sleutel ook met daarin een publieke sleutel. Met behulp van de publieke sleutel in het UZI-certificaat wordt het token op integriteit en authenticiteit getoetst, zie bijlage voor visuele toelichting o.a. toegang tot LSP Relatief hoge kosten PKIoverheid X.509 protocol o.a. toegang tot LSP Relatief hoge kosten User identificatie en wachtwoord Combinatie van een unieke user ID en wachtwoord Secure- DigID X.509 protocol Voor authenticatie patiënt IHE-XUA profiel Federatieve authenticatie & SSO Met het gebruik van XUA kan voor de raadpleging de authenticatie- en autorisatierollen worden doorgegeven Een trusted third party treedt op als Identity Provider Vaak gecombineerd met single-sign-on (SSO) toepassing IHE-XDS infrastructuur Bij toegangsbeheer tot verschillende systemen in meerdere instellingen Relatief onveilig t.o.v. X.509 protocol Momenteel is er geen eenduidig regionaal autorisatiebeleid en zal elke regio zijn eigen beleid moeten implementeren Organisatiekosten, stringenter toegangsbeleid voor sommige instellingen 17 1 Authenticatie heeft tot doel, met zekere waarschijnlijkheid, de identiteit van een gebruiker/systeem vast te stellen. De authenticatiecomponent controleert of een opgegeven bewijs van identiteit (attributen) overeenkomt met echtheidskenmerken en of deze valide is.

18 C. Inrichting 1. Identificatie 2. Authenticatie 3. Autorisatie 4. Logging D. Technische realisatie 3. Autorisatie

19 Implementatievragen bij behandelrelatie Waar en hoe wordt de behandelrelatie vastgelegd? Hoe is eenduidig vast te stellen of een behandelrelatie in het kader van dezelfde behandelovereenkomst is? Worden behandelrelaties op hetzelfde niveau vastgelegd? (individuele arts, afdeling, behandelteam, hele instelling) Hoe worden behandelrelaties eenduidig geborgd wanneer meerdere zorgverleners betrokken zijn bij het zorgproces? (bij een MDO of second opinion) Hoe wordt omgegaan met indirecte behandelrelaties? (bij het bevragen van een expert panel) 19

20 Implementatievragen bij het toestemmingsprofiel (1/2) Hoe vindt registratie van het consent plaats? En gedifferentieerd bezwaar? Geldt dit voor iedereen die informatie uit de registry opvraagt? Hoe vindt controle van het consent plaats? Waar wordt het consent opgeslagen (opt-in module?) en vastgelegd (individueel in iedere instelling?) Kan toestemming voor meerdere instellingen op één locatie worden vastgelegd Hoe worden toestemmingsverklaringen gedeeld met andere instellingen? Wordt consent generiek of specifiek vastgelegd? (specifiek voor individuele arts, afdeling, behandelteam, of hele instelling) Hoe wordt zorg gedragen voor een eenduidig regionaal beleid voor de invulling van toestemming? 20

21 Implementatievragen bij het toestemmingsprofiel (2/2) Wat is de procedure als een patiënt de toestemming wil intrekken? Kan dit ook vanuit een andere instelling? Hoe lang is toestemming geldig? (Nictiz-richtlijn is 5 jaar) Wat is het bereik van de gegeven toestemming? (landelijk, regionaal, affinity domain) Wat is de procedure indien geen toestemming wordt gegeven? (registreren van het niet geven van toestemming is ook een persoonsgegeven) 21

22 Verschil tussen veronderstelde en expliciete toestemming Toestemming van de patiënt voor de verstrekking van zijn patiëntengegevens mag worden verondersteld onder de volgende voorwaarden: de toegang wordt verleend in een concrete situatie (inclusief spoedeisende zorg); de patiënt redelijkerwijs kan verwachten dat toegang tot zijn patiëntengegevens wordt verleend gegevens voor zorgdoeleinden worden verstrekt (inclusief overdracht van zorg, zorgondersteuning zoals dossierbeheer, financiële afwikkeling en dergelijke); de patiënt tegen gegevensuitwisseling geen bezwaar heeft gemaakt; en de gegevensverstrekking beperkt blijft tot hetgeen noodzakelijk is voor de ontvanger. Dit is het geval bij push-verkeer. Van de patiënt moet expliciet om toestemming voor de verstrekking van patiëntengegevens worden gevraagd wanneer: patiëntengegevens worden verstrekt aan een andere hulpverlener met het oog op een nieuwe behandelepisode; patiëntengegevens worden verstrekt naar ontvangers buiten de gezondheidszorg (politie, justitie, werkgever, advocaat) en; patiëntengegevens worden verstrekt voor wetenschappelijk onderzoek. 22 Bron: Richtlijn voor implementatie van toestemmingsprofielen binnen XDS-netwerken, Nictiz (2012) Gedragscode Elektronische Gegevensuitwisseling in de Zorg (EGiZ, 2013)

23 IHE Toestemmingsprofiel: BPPC Basic Patient Privacy Consents provides a mechanism to record the patient privacy consent(s), and a method for Content Consumers to use to enforce the privacy consent appropriate to the use. This profile complements XDS by describing a mechanism whereby an XDS Affinity Domain can develop and implement multiple privacy policies, and describes how that mechanism can be integrated with the access control mechanisms supported by the XDS Actors (e.g., EHR systems). Toestemming van de patiënt (impliciet of expliciet) wordt vastgelegd in het profiel BPPC De toetsing van de behandelrelatie en het invullen van de patiëntrechten staat beschreven in de gedragscode Elektronische Gegevensuitwisseling in de Zorg (EGiZ, 2013) Bij een keuze voor pull verkeer gelden aanvullende patiëntrechten In NL bestaat onduidelijkheid of er wel of geen nieuw consent nodig is bij een second opinion (bijvoorbeeld door een andere patholoog) Er is geen duidelijk wettelijk kader over de vastlegging van toestemmingsprofielen, of dit middels een (digitale) handtekening dient te gebeuren of dat een vinkje volstaat BPPC 23

24 Implementatievragen bij inrichting autorisatiematrix Welke rollen zijn te definiëren? (incl. mandatering; relatie tussen UZI-nr. en gemandateerde) Welke rol heeft welke bevoegdheden t.a.v. het inzien van informatie? Welke rol heeft welke verantwoordelijkheden en bevoegdheden t.a.v. het publiceren van documenten? Welke documenttypes zijn geaccepteerd? Is er beleid omtrent wat acceptabel risico is? Is er beleid omtrent door de gemeenschap geaccepteerde derde partijen? 24

25 Aanbevelingen gebruikersidentificatie en autorisatie 1. Er is geen autorisatiebeleid op regionaal / landelijk niveau dus zal dit (in ieder geval per samenwerking) opgesteld moeten worden 2. Het komen tot het benodigde autorisatieprotocol / autorisatiematrix vereist het vastleggen van gebruikshandelingen per type beroepsbeoefenaar (a.d.h.v. BIGrolcodes) en per zorgtoepassing. Dit dient afgestemd te worden met een autorisatiecommissie. Al met al kan dit een meerjarig traject zijn waar vroegtijdig rekening mee dient te worden gehouden 3. Authenticatie- en autorisatierollen kunnen worden doorgegeven middels het XUA en XUA++ profiel 25

26 C. Inrichting 1. Identificatie 2. Authenticatie 3. Autorisatie 4. Logging D. Technische realisatie 4. Logging

27 Implementatievragen bij logging Waar en hoe kan de patiënt twijfels op rechtmatigheid of juistheid uiten? Hoe vindt controle op logging plaats? Realtime en achteraf? Wie krijgt toegang tot logging? Wie acteert op afwijkingen? 27

28 Aanmelden of opvragen van patiëntgegevens vereist het bijhouden van de volgende loggegevens Het type transactie (opvraging, aanmelding) BSN nummer UZI-nummer en UZI abonneenummer (URA) van de beroepsbeoefenaar Het soort gegevens dat is verwerkt Datum en tijdstip van verwerking (indien van toepassing: mandaterende zorgverlener) 28 Voor relevante documentatie wordt verwezen naar het loggingsbeleid van de AORTAinfrastructuur: bijlage 6 van het Convenant digitale beeld- en verslaguitwisseling (Nictiz, 2011)

29 IHE Authenticatie & Logging profiel: ATNA Audit Trail and Node Authentication establishes the characteristics of a Basic Secure Node: 1. It describes the security environment (user identification, authentication, authorization, access control, etc.) assumed for the node so that security reviewers may decide whether this matches their environments. 2. It defines basic auditing requirements for the node 3. It defines basic security requirements for the communications of the node using TLS or equivalent functionality. 4. It establishes the characteristics of the communication of audit messages between the Basic Secure Nodes and Audit Repository nodes that collect audit information. 5. It defines a Secure Application actor for describing product configurations that are not able to meet all of the requirements of a Secure Node. Authenticatie van gebruiker Alleen lokale gebruikersauthenticatie benodigd. Iedere beveiligde node gebruikt eigen technologie voor toegangscontrole. Authenticatie van de verbinding Vereist bi-directionele op certificaten gebaseerde node authenticatie. [ATNA] 29 Audit Trails Een security officer in een instelling moet activiteiten kunnen nagaan om naleving van het beleid te beoordelen en om niet-conform gedrag en onjuiste bewerkingen van beveiligde patiëntgegevens te detecteren.

30 C. Inrichting 1. Identificatie 2. Authenticatie 3. Autorisatie 4. Logging D. Technische realisatie Technische realisatie

31 Inhoud 1. Netwerk & Firewall 2. Koppelingen 3. Backup & herstel, onderhoud 4. Beveiligingsbeleid 5. Informatieve plicht + inrichting patiëntrechten 6. Hosting XDS omgeving, serverlocatie

32 Netwerk & firewall Wordt gebruik gemaakt van het internet (met VPN) of een secure netwerk? Welke netwerktopologie wordt gekozen? (Maasnetwerk, Sternetwerk, Busstructuur, Ringnetwerk, etc.) Hoe worden VPN-verbindingen beheerd? En is dit beheermodel schaalbaar wanneer meerdere instellingen aansluiten? (vanwege snel toenemend aantal VPN-verbindingen) Welke beschikbaarheidsgaranties en service(reactie)tijden worden afgesproken? Met wie kan men contact opnemen bij vragen of fouten? 32

33 Koppelingen Welke bronsystemen dienen ontsloten te worden? Hoe kunnen leveranciers in een vroeg stadium betrokken worden? Welke koppelingen dienen gerealiseerd te worden? 33

34 Back-up & herstel, onderhoud Hoe vaak vindt back-up plaats? Wat is de herstelprocedure in geval van fouten? Welke afspraken worden gemaakt t.b.v. onderhoud? 34

35 Beveiligingsbeleid Hoe wordt het beveiligingsbeleid ingericht in termen van: Vertrouwelijkheid Integriteit Beschikbaarheid Onweerlegbaarheid 35

36 Informatieve plicht, inrichting patiëntrechten Hoe wordt omgegaan met de inrichting van patiëntrechten en het verstrekken van informatie daarover naar de patiënt in termen van: Inzage en afschrift Correctie Bezwaar Toestemming Vernietiging Hoe worden patiënten geïnformeerd wanneer het affinity domain wordt uitgebreid? 36 Voor meer informatie over de rechten van de patiënt wordt verwezen naar de Gedragscode EGiZ (2013) en het Convenant privacy & security van Nictiz (2011)

37 Hosting XDS omgeving, serverlocatie Welke eisen en wensen worden aan de prestatie gesteld? Hoe snel moeten gegevens aangemeld zijn op- en op kunnen worden gehaald van de registry? Wie is beheerder en wie is eigenaar van de IHE registry? Wat is het protocol als er iemand anders (dan de verantwoordelijke voor de registry) wil aanleveren c.q. ophalen uit de registry? Staat dit uitwisseling in de weg? Hoe faciliteert dit nieuwe uitwisselingen? Is XCA hier het profiel voor? Welke afspraken worden daar onderling over gemaakt? Worden er (verplichte) afspraken gemaakt over de XDS consumer? Komt er 1 centrale consumer? Heeft iedere instelling zijn eigen consumer? 37

38 Praktische informatie

39 De stakeholders voor ieder project zijn in vier categorieën te delen: allen dienen vroegtijdig te worden betrokken Beslissers Bestuurders Security officers Leveranciers Leveranciers XDS Project Gebruikers Zorgverleners Administratieve afdelingen Radiologiemedewerkers Uitvoering Projectleider Projectleden IT afdeling & medewerkers Communicatie-afdeling 39

40 Grof stappenplan 1. Bestuurlijk akkoord & afspraken vastleggen in convenant 5. Afspraken over vastlegging van toestemming patiënt 2. Organisatorische inrichting project (planning en inzet van mensen en middelen) 6. Ontwerp technische inrichting 3. Afspraken over autorisatie (opstellen autorisatiematrix o.b.v. behandelrelaties) 7. Ontwerp technische realisatie 4. Afspraken over authenticatie van patiënt en zorgverlener 8. Implementatie 40

41 Lijst met producten die een project zou moeten opleveren Samenwerkingsovereenkomst (vanwege gezamenlijke verantwoordelijkheid over de gegevens in de registry) Aansluitdocument Privacybeleid Netwerktopologie XDS-componententopologie SLA (service level agreement) 41

42 Risico s en belangrijke interventies Risico Beperkte kennis bij leveranciers en ziekenhuizen; XDS-compliant betekent niet altijd hetzelfde; Vaak wijzigende firewallinstellingen; Vele partijen die niet op één lijn zitten; Te ambitieuze tijdplanning; Onvoorziene kosten zoals switches, connectoren, vertalers, adviseurs, leveranciers die extra geld vragen, etc. Interventie Leer van andere trajecten (zie volgende slide) Zorg dat leveranciers de aansluitdocumentatie op orde hebben en gedeeld Betrek IT afdeling op tijd en maak duidelijke afspraken en procedures bij wijzigingen Zorg voor een gedeelde bestuurlijke visie als uitgangspunt Leer van andere trajecten (zie volgende slide) en wees voorbereid op inrichtingsvragen Leer van andere trajecten (zie volgende slide) en maak service-afspraken over implementatie 42

43 Ervaring met XDS Klik op de kaart voor een overzicht van XDS-omgevingen wereldwijd Op de website van IHE Nederland staat een overzicht van succesverhalen Klik op de logo s rechts voor leveranciers van XDS oplossingen in Nederland Klik hier voor een overzicht van resultaten wereldwijd 43

44 Landelijke ontwikkelingen XDS Diverse regio s en RSO s beschikken over een XDS infrastructuur, klik op de kaart voor een interactief overzicht Voor zover bekend voorziet het LSP (VZVZ) nog niet in de mogelijkheid op XDS aan te sluiten. 44

45 Relevante documentatie Documentnaam IHE_ITI_TF_Vol1 Richtlijn toepassing BPPC v1.0 Gedragscode EGiZ Checklist beelduitwisseling UMC Utrecht Vertrouwensmodel landelijke infrastructuur Auteur / instantie IHE Nictiz RSO s, Nictiz Sjaak Gondelach, UMCU Nictiz KA11004C Eindrapportage e-radiologie Convenant privacy en security v1.0 Nictiz, EZDA Ontwerp Authenticatie Nictiz (2011) Patiënt identificatie en authenticatie voor zorgportalen Nictiz (2010) Handreiking patiëntauthenticatie Nictiz (2013) 45

46 Co-auteurs & review Wijnand Weerdenburg Zorgportaal Rijnmond Martijn Bakkers Medischegegevens.nl Sven Pippel Forcare B.V. Robert Breas MedicalPHIT Jasper van Sambeek Sleutelnet B.V. 46

47

48 a t e Soulve Innovations Goeman Borgesiuslaan ET Utrecht Jelmer.Kranenburg@soulve.nu Jeroen van Dalen en Jelmer Kranenburg

49 Bijlagen

50 Onderdelen buiten scope van presentatie A. ORGANISATIE Type informatie-uitwisseling Welke (meta-)data Welke bestandstypen B. ONDERHOUD Beleid omtrent misbruik Consequenties Bewaartijd van informatie Procesbeschrijvingen Registratie consent Wettelijke rechten patiënt Break-the-glass procedure Use-cases Triggers voor informatie-uitwisseling Vastleggen afspraken in convenant Keuze en afspraken leverancier, eigenaarschap Kostenverdeling partners Communicatie (intern & extern) en support 50

51 Relevante profielen bij IHE-XDS Cross-enterprise Document Sharing PIX: Patient Identifier Cross-referencing PDQ: Patient Demographics Query NAV: Notification of Document Availability Security / Privacy ATNA: logging & audit trail (Audit Trail & Node Authentication) CT: Consistent Time BPPC: Basic Patient Privacy Consent XUA en XUA++: Cross-enterprise User Assertion DSG: Document Digital Signature 51 Trial implementation (tekst is nog niet definitief) Complexity (zijn doorgaans complex bij implementatie)

52 Overige relevante profielen XDS-I.b (imaging) XDS-SD (scanned documents) XDR (Cross-enterprise Document Reliable Interchange XCA (Cross Community Access) RFD (Retrieve Form Data Capture) XDW (Cross Enterprise Workflow) DSUB (Document Metadata Subscription) 52