DISCUSSIEPUNTEN HANDREIKING INTEROPERABILITEIT TUSSEN AFFINITY DOMAINS

Transcriptie

1 DISCUSSIEPUNTEN HANDREIKING INTEROPERABILITEIT TUSSEN AFFINITY DOMAINS Revisiebeheer Versie Datum Auteur Toelichting Status Vincent van Pelt Eerste concept Concept Vincent van Pelt Aanvullingen na updates Concept 2014 hoofddocument Vincent van Pelt Na alle reviews Definitief LEESWIJZER Dit document beschrijft de discussiepunten die nog open staan ten aanzien van versie 1.2 van de Handreiking Interoperabiliteit tussen XDS Affinity Domains. In de rest van dit document wordt de verkorte term Handreiking gebruikt. Aangezien dit document ook voor eerdere versies van de Handreiking is gebruikt, behouden de discussiepunten hun oorspronkelijke volgnummers. Discussiepunten die al zijn afgehandeld staan tussen haakjes, de conclusies of oplossingen van de afgehandelde discussiepunten staan erbij vermeld. De overige discussiepunten zullen niet in de huidige versie van de Handreiking worden opgelost. Een volgende versie van de Handreiking wordt voorbereid. Voor de openstaande discussiepunten wordt een roadmap opgesteld. Legenda EA Jan Feenstra, Gerrit JS Jeroen Straatman, Ezda VvP Vincent van Pelt, Nictiz RH Renie Heerbaart, IZIT WW Wijnand Weerdenburg, RijnmondNet 230: citaat uit de handreiking DISCUSSIEPUNTEN

2 1. (HOE NORMATIEF IS DE HANDREIKING?) Moeten de voorwaarden van de Handreiking gezien worden als aanbevelingen, of gelden zij als aansluitvoorwaarden? Besluit van het Regioplatform: de voorwaarden zoals die in Hoofdstuk 2 zijn opgesteld gelden als verplichtend voor aansluiting bij de netwerken van de bij het Regioplatform aangesloten Regionale Samenwerkings Organisaties (RSO s). Zie het document Oplegger Handreiking interoperabiliteit-0.2.docx. 3. (OP WELKE WIJZE EN DOOR WIE MOET ER WORDEN GEKWALIFICEERD?) Hoe en door wie wordt conformance aan de aansluitvoorwaarden van de Handreiking georganiseerd? Zie het document Governance Handreiking Interoperabiliteit tussen Affinity Domains V02.docx 4. PATIENT CONSENT, BPPC Hoe dient de autorisatie te worden ingericht (in BPPC)? Voor de inrichting van toestemmingsprofielen met gebruikmaking van BPPC, zie het Nictiz document: Richtlijn voor implementatie van toestemmingsprofielen binnen XDS-netwerken ( ). RH: tot nu toe moet een patiënt alleen toestemming geven voor beschikbaar stellen van informatie, niet voor inzage. Dat wordt met de nieuwe wet mogelijk anders. Er moet nog worden uitgewerkt hoe toestemming van de patiënt voor inzage van gegevens vanuit een andere regio wordt vastgelegd (sen gecommuniceerd aan de patiënt) De wetgeving (met name de Wet Cliëntenrechten) is nog niet van kracht. Daarnaast blijft een aantal vragen open die onder andere te maken hebben met het feit dat het BPPC profiel eigenlijk onvoldoende mogelijkheden biedt om de gewenste functionaliteit te leveren. Conclusie: er is nog onvoldoende zekerheid over de wetgeving, er kunnen nog BPPC nog te ft nog een aantal discussiepunten over, die we in een volgende versie van de Handreiking willen oplossen. Voor 2015 blijft bovenstaand document de richtlijn. Nieuwe input, Review leveranciers, 9 juni 2015: Sven Rietstra, Topicus: - Het lijkt erop dat het document er op stuurt om het afdwingen van BPPC policies bij de XDS consumers te leggen. Hoewel dit volgens BPPC profiel correct is, sturen andere IHE profielen er inmiddels op aan om dit soort autorisatie beslissingen bij de registry te leggen (zie bijvoorbeeld het SER profiel). Het centraal leggen van dit soort beslssingen levert een aantal belangrijke beslissingen: - Veranderingen in de beschikbare BPPC policies hebben alleen impact op de registry in plaats van op alle consumers. - Autorisatie wordt op 1 plek afgedwongen en is daardoor beter controleerbaar. - BPPC policies worden binnen het affinity domain afgedwongen, andere affinity domains hoeven daarom geen weet te hebben van de geldende BPPC policies.

3 Vanwege deze voordelen wil ik er voor pleiten om het afdwingen van de BPPC policy bij voorkeur centraal te laten plaatsvinden, danwel op de gateway waardoor policies altijd binnen het affinity domain afgedwongen worden. 5. (GOVERNANCE ) Zie het document Governance Handreiking Interoperabiliteit tussen Affinity Domains 6. (!!WIJZIGINGSVOORSTELLEN (GOVERNANCE)) Zie het document Governance Handreiking Interoperabiliteit tussen Affinity Domains Nieuwe inbreng, leveranciersreview: Sven Rietstra, Topicus: In hoofdstuk staat: In deze procedure is ook vastgelegd hoe aanpassingen aan de XDS metadataset worden geregeld. Uitgangspunt is, dat er periodiek een update wordt gepland, die door alle Affinity Domains op hetzelfde moment wordt geïmplementeerd, op basis van de nieuwe versie van het Dataset XDS document. Het lijkt mij onhaalbaar om alle affinity domains op hetzelfde moment een update te laten doorvoeren, zeker als het aantal affinity domains nog gaat stijgen. Een periode waarbinnen iedereen de update moet doorvoeren lijkt me realistischer. 7. (SERVICEDESK) Hoe wordt de servicedesk geregeld? Elk Affinity Domain is verantwoordelijk voor het operationeel zijn en het beheer van alle eigen systemen, dus ook van de Gateways. Zie verder de Handreiking, hoofdstuk (BSN) Hoe wordt omgegaan met het BSN? Uitwisseling van patiëntgegevens is uitsluitend toegestaan op basis van een gevalideerd Burger Servicenummer (BSN) en alleen wanneer de patiënt toestemming heeft gegeven voor het uitwisselen van gegevens. Zie de Handreiking, hoofdstuk 2.6.5, en RH: er is nu net een heel gedoe over het gebruik van BSN door niet-zorgaanbieders. Die mogen BSN wel gebruiken als ze aan de NEN 7510:2011 voldoen. Wel goed om daarover iets op te nemen.

4 1280: Uiteraard zijn er patiënten denkbaar die geen BSN hebben, zoals toeristen, pasgeboren baby s of gedetineerden. Het ministerie van Binnenlandse zaken heeft een lijst met tijdelijke BSN s beschikbaar om patiënten zonder BSN een tijdelijk ID te geven. Het is aan de zorginstellingen om deze tijdelijke BSN s te gebruiken. JS: voorstel van RAP WW: Goed om hier met een praktisch voorstel te komen daar dit bij ieder project / regio terug gaat komen en vertragend kan werken indien hier nog geen ei is over gelegd. Discussie (VvP): RAP dient hier een beslissing over te nemen, dan kan het in de Handreiking worden opgenomen. Voorstel: afhandelen volgens de bestaande procedures, ook BSN door nietzorgaanbieders. 9. ENCRYPTIE VAN BESTANDEN Dit onderdeel zal in een latere versie van de Handreiking worden opgenomen. 10. AUTHENTICATIE 780: Voor toegang tot de Registry door geautoriseerde gebruikers is een UZI-zorgverlenerspas, UZIpas op naam of een vergelijkbare smartcard oplossing vereist. Registratie van UZI-pas- of smartcardgegevens vindt plaats bij de beheerder van de registry. JF: Of toegangsmiddelen die aan E-id voldoen. Welk STORK niveau moet aan voldaan worden?? Dit lijkt me beter dan te eisen dat het UZI pas moet zijn. Als het bijvoorbeeld STORK 3 is of Stork 2 zijn er meerdere mogelijkheden. 800: Systemen die over het Affinity Domain communiceren, doen dit op basis van tweezijdig geauthenticeerde TLS verbindingen en uitsluitend op basis van UZI-servercertificaten. JF: Waarom UZI. Sommige ziekenhuizen leveren ook zelf certificaten die kunnen worden toegepast? RH: Gebeurt dit via een standaard? Note: dat kunnen bijvoorbeeld ook UZI server certificaten zijn. Of PKI overheid. 890: Voor het uitwisselen van gegevens zijn certificaten nodig die de systemen authenticeren. Hiervoor dienen deze systemen UZI servercertificaten geïnstalleerd te hebben. JF: Het is de vraag of alle RSO s zich hier in kunnen vinden. We kunnen ook afspreken dat er een tweeweg certificaat wordt gebruikt tussen beide systemen. Aangezien het netwerk al besloten is is dit een eerste veiligheids niveau, de tweede is dat er certificaten worden ingezet. Discussie (VvP): overleg RAP. Misschien de eis wat algemener stellen, bijvoorbeeld dat STORK 3 moet worden geïmplementeerd. Dan hoef je het niet op implementatieniveau te beschrijven, is ook toekomstbestendiger.

5 11. (WET- EN REGELGEVING) Welke wetten zijn relevant, en welke normen en richtlijnen vormen de basis van de aansluitvoorwaarden? Verwijzen naar EGIZ. Hier komt een nieuwe versie van gebaseerd op de laatste wet en regelgeving. 12. METADATASET XDS EN LOGGING 1250: Tussen Affinity Domains moeten wel afspraken gemaakt worden welke (extra) transacties en welke metadatagegevens vastgelegd worden in de logging. Alle zorginstellingen van het Affinity Domain moeten zich hier aan houden. Om te voorkomen dat een set voor metadata binnen elk Affinity Domain opnieuw uitgevonden wordt, is een nationale metadataset ontwikkeld. JF: Classcode Het advies vanuit NICTIZ is om voor de classcode bij Beelden KOS te gebruiken (code ). Het document waarmee de beelden (dus niet het rapport) in de registry wordt aangemeld heet bij XDS het KOS omdat het o.a key images kan bevatten en verder verwijst naar de oorspronkelijke beelden. Typecode Voor TypeCode zegt de XDS-i definitie dat daar de 'requested procedure code' in vermeld moet worden. Er is geen standaardlijst met CTG of CBV codes. Vanuit NICTIZ is men daar niet aan begonnen om dat er wordt gewerkt aan een nieuwe verrichtingen thesaurus. Dat zou een goede en toekomstvaste kandidaat zijn voor een standaardlijst. Tot die tijd is het advies van NICITZ om het met een (bilateraal afgesproken) lijstje met CTG of CBV codes te doen. Het is ook een overweging om een heel algemene code te gebruiken. Alle metadata is uiteindelijk alleen bedoeld om selectie te vereenvoudigen. De eerste tijd zullen er per patiënt geen honderden beeldstudies staan, zodat selectie niet echt een probleem is, zeker niet als de classcode en de eventcode gevuld worden. EventCode De modaliteit en eventueel lichaamsdeel wordt in EventCode gemeld Deze wordt op het ogenblik niet gevuld binnen XDS en moet dus worden toegevoegd. JS: iets voor het RAP of een subcommissie? JS: zijn er afspraken gemaakt over beheer van de metadataset en het aanmelden/accorderen van wijzigingen? RH: ik denk dat jullie met een voorstel moeten komen. JF: Zie meegestuurd XDS Metadatadocument GERRIT. Deze versie is slechts een concept dus nog niet definitief. Zie bijlagen A en B (paragraaf 3.10) onderaan dit document

6 WW: Goed om hier nog meer aandacht aan te schenken daar we in de regio Rijnmond en Breda al diverse metadataset hebben. Wat is de rol van Nictiz hierin? Nieuwe toevoeging, SDSK, Mirjam Bos: Zorg ervoor dat de patiënt ook toegang heeft tot de logging gegevens van ATNA. Discussie (VvP): Toets de huidige XDS Metadataset aan de eigen implementatie en kijk wat er nog moet worden afgesproken / geharmoniseerd. Voorstel 1: hiervoor een apart subprojectje opzetten, en in de Handreiking alleen naar de XDS Metadataset verwijzen. IS IN UITVOERING Voorstel 2: breng het beheer van de metadataset onder bij Nictiz. Voorstel inzage logging-gegevens patiënt: wordt in de volgende versie van de Handreiking verder uitgewerkt. 13. ZORGVERLENERGIDS 1295: Een zorgverlenergids zorgt er dan voor, dat de patiënt een specifieke zorgverlener toegang kan verlenen tot medische gegevens of deze toegang juist weigeren. De zorgverlenergids hoeft niet per se op landelijk niveau georganiseerd te zijn. Dit kan ook op het niveau van een Affinity Domain zijn.. <Vraag: maar hoe geef je dan toestemming aan een arts is een andere regio?> JS: graag een landelijke zorgverlenergids opzetten en onderhouden RH: dat is dus onwenselijk, laten we dit juist landelijk doen, liefst nog samen met vzvz Discussie (VvP): een landelijk opvraagbare zorgverlenergids moet er volgens mij gewoon komen. Eventueel met locale / regionale subsets. Wel discussie nodig over toevoeging van niet-artsen. 14. BEELDEN OPHALEN Afhankelijk van de systemen kunnen beelden op verschillende manieren opgehaald worden. Beelden kunnen vanuit de imaging document consumer Actor via een RAD-69 transactie opgehaald worden. Een alternatief is om dit via WADO (Web-Access to DICOM Objects (de RAD 55 transactie)), of DICOM Query Retrieve (RAD-16) transactie te doen. Hiervoor moeten tussen de uitwisselende partijen duidelijk afspraken gemaakt zijn. <Vraag: wat zijn hierbij jullie voorkeuren?> JS: vraag voor het RAP Discussie (VvP): eens. Zetten in roadmap? RAD > RAD 69 (=voorwaarde XCA). 15. TESTEN

7 RH: moeten er ook nog eisen opgenomen worden die gesteld worden aan de test- en acceptatieomgeving? Discussie (VvP): staat al deels in tekst. Misschien eigen verantwoordelijkheid? 16. SAMENWERKINGSCONVENANT 1020: Afspraken Niveau beleid en organisatie JS: convenant tussen alle betrokken partijen en de RSO, waarin de verschillende onderliggende overeenkomsten zijn beschreven. Raamovereenkomst met bijlagen, waaronder aansluitvoorwaarden en bewerkersovereenkomst. Interregionaal convenant tussen de affinity domains lijkt me ook een must. Discussie (VvP): eens, is ook al in de planning om te worden opgenomen in de handreiking. 17. ROLLEN EN RECHTEN 1279, (versie 7c) Autorisatie: Voor toegang tot de registry wordt gewerkt met een rollen/rechten structuur waarmee geautoriseerde gebruikers uitsluitend toegang krijgen tot delen van de applicatie waar zij toe gerechtigd zijn. Zij krijgen alleen die informatie te zien waar patiënten toestemming voor hebben gegeven Welke rollen en rechten moeten er gebruikt worden? Zie ook ELGA Opmerking [k1]: Welke rollen/rechten? Wie wijst deze toe? VvP: dit wordt een actiepunt voor het Regioplatform. Ook verwachten we nog een stuk document 18. WAARDENLIJSTEN XDS METADATA 1493 (versie 7c) Binnen een Affinity Domain moet een procedure worden ingericht om ervoor te zorgen dat de laatste versie van de metadataset in gebruik is, om eventuele uitwisselingsproblemen met andere 19. LOCATIE XDW METADOCUMENTEN Opmerking [k2]: Vraag: is hier al praktische ervaring mee? VvP: nee. We spreken af dat het een dynamische set is. Updaten van de lijst zou via SVS (of gewoon ) kunnen worden geüpdatet. Nog discussie Regioplatform. Uit de Handreiking Interoperabiliteit tussen XDS Affinity Domains:...Het alternatief is, dat een update van een XDW-document plaats vindt in het Affinity Domain waar de patiënt zich op dat moment bevindt. In het laatste geval moet er een bericht naar het andere Affinity Domain gaan dat er voor zorgt dat het oude XDW-document als verouderd (obsoleet)

8 verklaart zodat deze niet meer als resultaat op een zoekvraag verschijnt. In beide gevallen speelt het recht om een document aan te kunnen melden of te kunnen wijzigen in een ander Affinity Domain een belangrijke rol. Welk alternatief moet worden gekozen is afhankelijk van de keuze die door IHE International wordt uitgewerkt. Dit zal in een volgende versie van de Handreiking verder worden uitgediept (zie ook het Discussiepunten document). Vraag: voor welke oplossing wordt gekozen? Zal in een volgende versie van de Handreiking worden uitgewerkt, zodra IHE hierover uitsluitsel geeft.