Molengracht, Breda IMT
Notitie Van
Ulco Woudstra
Aan
Project Uitwisseling via PGD
Directe telefoon Email
Ons kenmerk Datum Onderwerp
14 augustus 2014 Globaal technisch ontwerp POC uitwisseling via PGD V10
Pagina
1/10
1. Inleiding In deze notitie wordt het globale technisch ontwerp betreffende de uitwisseling via PGD uitgewerkt, zoals beschreven in het betreffende beslisdocument (zie bijlage 1). Hieruit is overgenomen de volgende figuur 1, waarin op gegevens/informatie-niveau wordt weergegeven hoe de uitwisseling tussen de verschillende elementen plaatsvindt.
Figuur 1: Beschrijving systeem op gegevens/informatie-niveau
Molengracht, Breda Van Datum Onderwerp Pagina
Ulco Woudstra 14 augustus 2014 Globaal technisch ontwerp POC 2/10 Toelichting op de nummers in Figuur 1 en de verdere uitwerking op gegevens/informatieniveau (zie de sub notering a,b, c etc.). 1) Beelden en verslagen uit het PACS worden aangemeld bij de UPZuid registry; a.
Dit is een bestaande werkwijze die niet wordt aangepast.
b.
Tevens wordt door Amphia een BPPC document aangemeld bij de registry, d.w.z. de patiënt wil de gegevens delen met zorgverleners in de volgende fasen van het behandelingsproces.
2) Het medisch dossier (medicatie, labverslagen, etc.) wordt uit EPIC ontsloten en zichtbaar gemaakt voor de patiënt (en externe zorgverlener) via de patiëntinterface. Voor het creëren van inzage in het medisch dossier wordt gebruik gemaakt van MyChart (en Carelink), het patiëntportaal van Epic; a.
Deze standaard componenten van Epic worden as-is gebruikt. De identificatie/autorisatie verloopt via de patiëntinterface van Meddex.
3) De patiënt kan beelden en verslagen via de patiëntinterface raadplegen; a.
De patiënten die toegang krijgen om te kunnen raadplegen worden gekenmerkt door een “Meddex-vinkje” in Epic (Mychart active flag). Dat wil zeggen door een Amphia-medewerker wordt in Epic aangegeven dat de betreffende patiënt toegang krijgt tot de patiëntinterface van Meddex.
b.
Door Meddex wordt dit vinkje 8 maal per dag geraadpleegd en worden NAW patiëntgegevens uit Epic geladen in Meddex. Dit betreft de volgende gegevens: i.
BSN
ii.
Amphia patiënt nummer
iii.
Achternaam
iv.
Voorvoegsel (van der, van, etc..)
v.
Meisjesnaam (indien aanwezig)
vi.
Voorvoegsel meisjesnaam
vii.
Voorletters
viii.
Voornaam
ix.
Geslacht
x.
Geboortedatum
xi.
Adres
xii.
Huisnummer
xiii.
Postcode
xiv.
Woonplaats
xv.
E-mail
xvi.
(Mobiel) Telefoon
4) De patiënt geeft toestemming of medische gegevens beschikbaar mogen worden gesteld aan Verbeeten. Dit consent wordt apart vastgelegd: voor beelden en verslagen wordt het consent via UPZuid vastgelegd; voor de medische gegevens wordt het consent in Epic vastgelegd.
Molengracht, Breda Van Datum Onderwerp Pagina
Ulco Woudstra 14 augustus 2014 Globaal technisch ontwerp POC 3/10 a.
Het consent voor UPZuid wordt vastgelegd via het XDS BPPC document. Door Meddex kan alleen toestemming worden verleend op het niveau van zorgverlener.
b.
Het consent in Epic kan alleen worden vastgelegd op het niveau “alles of niets” d.w.z. de indicator toestemming (WGBO TOESTEMMING EXTERN (ID 3041302351)) staat op “ja” of “nee”. Deze wordt standaard op ja gezet door Amphia (zie bovenstaand punt 1).
c.
De vertaling van niveau a naar niveau b wordt als volgt uitgevoerd: i.
In Meddex wordt de betreffende radiotherapeut van Verbeeten opgenomen. Als de patiënt inlogt in Meddex, dan wordt deze radiotherapeut vermeld.
ii.
Als de patiënt zijn toestemming wil intrekken, dan wordt de naam van de radiotherapeut verwijderd door de patiënt. Het Meddex systeem geeft dan de volgende signalen: 1.
Naar UPZuid registry: een BPPC document met een negatief consent.
2.
Naar Epic: een mail naar een Amphia e-mail adres met de mededeling dat het “toestemmingsvinkje” op nee moet worden gezet. Dit wordt handmatig uitgevoerd door een Amphia medewerker.
iii.
Als de patiënt opnieuw toestemming wil geven, dan moet minimaal één naam van een radiotherapeut weer worden ingevuld. Meddex stuurt dan de volgende berichten: 1.
Naar UPZuid registry een BPPC document met een generiek positief consent
2.
Naar Epic: een mail naar een Amphia e-mail adres met de mededeling dat het “toestemmingsvinkje” op ja moet worden gezet. Dit wordt handmatig uitgevoerd door een Amphia medewerker.
5) De patiënt voert beheer over de toegang tot het medisch dossier, de beelden en verslagen door toestemmingen in te trekken via de patiëntinterface; a.
Zie bovenstaand punt 4
6) Medewerkers uit het Verbeeten instituut raadplegen zowel het medisch overdrachtsdossier (uit Epic) als radiologische beelden en verslagen (uit UPZuid) - indien de patiënt toestemming heeft gegeven tot beide; a.
UPZuid: als BPPC generiek consent positief, dan krijgen alle gebruikers toegang; als negatief, dan krijgt geen gebruiker toegang.
b.
Epic: de Verbeeten gebruiker kan het toestemming-vinkje raadplegen om te weten of de patiënt toestemming heeft gegeven.
7) Een patiënt kan gegevens toevoegen aan de patiëntinterface, optioneel kunnen deze ook worden gepubliceerd op de registry waarbij de patiëntinterface als ‘source’ geldt. a.
Deze functionaliteit is nog niet ingevuld.
Molengracht, Breda Van Datum Onderwerp Pagina
Ulco Woudstra 14 augustus 2014 Globaal technisch ontwerp POC 4/10
2. Ontwerp op applicatie-niveau De in Figuur 1 getekende patiënt interface wordt in onderstaande Figuur 2 weergegeven als Meddex, met connecties naar UPZuid en Epic/Amphia.
Figuur 2: Connecties van Meddex met UPZuid en met Epic. Opmerkingen: In Figuur 2 is alleen Epic Mychart getekend (en hieraan wordt Carelink toegevoegd). De PDQ (NAW gegevens) komt niet uit UPZuid maar uit Epic. (zie 1.3.b) De verbinding naar de initiating gateway loopt fysiek via Intermax (stercommunicatieconcept).
Molengracht, Breda Van Datum Onderwerp Pagina
Ulco Woudstra 14 augustus 2014 Globaal technisch ontwerp POC 5/10
De communicatie tussen de XDS consumer en de UPZuid registry en de Amphia repository (initiating gateway) is volgens standaard XDS regels. De intelligentie van de vertaling van het BPPC op niveau zorgverlener naar BPPC conform Amphia (Zie paragraaf 1 punt 4) wordt uitgevoerd binnen Meddex. Dus UPZuid hoeft hiervoor niets aan te passen. De communicatie van Meddex naar Mychart/Carelink is slechts op basis van een URL die wordt aangeroepen (identificatie/authenticatie wordt in paragraaf 3 uitgewerkt). De gebruiker komt dan in een apart tabblad in Meddex terecht en komt weer terug in Meddex als de applicatie Mychart/Carelink wordt gestopt. Door Meddex wordt het patiënt BSN meegegeven zodat Epic Mychart/Carelink meteen de betreffende patiëntgegevens kan tonen (na vertaling van BSN in Amphia patiëntennummer). De URL voor Mychart bevat Amphia patiëntennummer; de URL voor Carelink bevat AGB code zorgverlener plus Amphia patiëntennummer. De communicatie tussen Meddex Connector en de Epic database betreft de volgende gegevens: Het raadplegen van het toegangsvinkje (paragraaf 1.3) en het ophalen van de NAW gegevens. De communicatie tussen Meddex Backend en Epic gaat via het versturen van een mail in Outlook. 3. Ontwerp op infrastructuur-niveau In de bijlage 2 wordt een overzicht gegeven van de infrastructurele componenten in hun onderlinge samenhang. Hierbij wordt onderscheid gemaakt tussen de gebieden Untrusted (rood, Meddex), Trusted (groen, Amphia LAN), Security (geel, Amphia DMZ) en Federated (blauw, UPZuid en trusted XDS relaties) . In de bijlage 3 wordt uitgelegd wat het principe is van ADFS en claimbased authentication, dat wordt gebruikt om Meddex op een vertrouwde manier de identificatie en authenticatie te laten doen voor Amphia. In bijlage 4 wordt dit verder uitgewerkt op functioneel niveau. Bijlagen 2 en 3 zijn niet noodzakelijk voor niet-technische mensen om paragrafen 1, 2 en 4 te begrijpen. De in figuur 2 genoemde relaties worden in bijlage 2 weergegeven. De basis hiervoor zijn VPN site2site verbindingen tussen Intermax, Amphia en Rekencentrum Meddex. De verbindingen Intermax – Meddex en Amphia – Meddex zijn inmiddels aangelegd. De XDS communicaties (blauwe pijlen) betreft XDS standaarden.
Molengracht, Breda Van Datum Onderwerp Pagina
Ulco Woudstra 14 augustus 2014 Globaal technisch ontwerp POC 6/10 De gestippelde lijn tussen de PDQ consumer en Epic betreft punt 3 van paragraaf 1. Dit kan worden opgeleverd door Epic (elke 2 uur worden overdag gegevens ververst).
4.
Uitgangspunten t.a.v. beveiliging
De toegang tot gegevens is tweeledig, een gedeelte wordt door Meddex afgedicht en een gedeelte ligt bij Amphia. Hackers slaan toe op functioneel en technisch gebied en proberen combinaties te vinden om er tussen te kunnen breken. Daar hebben we in het ontwerp al veel rekening mee gehouden. De ingang: Meddex heeft een methodiek om inloggen te beveiligen. Dit is gebaseerd op gegevens, welke Amphia aanleverd (naam, email, telefoon) waarmee een veilige verbinding wordt gerealiseerd. Dit wordt gedan op basis van meervoudige herkenning. De gegevens staan vast (naam, email) en via (telefoon, SMS) wordt extra gecontroleerd of de gebruiker is voor wie hij zich uitgeeft. (Weten van gegevens en hebben van middelen). Op dat moment kan Meddex een veilige connectie opzetten. Een veilige connectie kan een veilige sessie opzetten, als de twee eindpunten voldoen aan de goed beheerde standaard (gepatched, antivirus up-to-date, firewall, geen mallware). Daarnaast dienen de eindpunten alleen toegankelijk te zijn voor de betreffende gebruikers. XDS sessie: De sessie die met Meddex is opgezet, kan verlengt worden met SAML tokens naar het XDS affinity domein. Binnen het XDS domein gelden dezelfde regels rondom endpoint beveiliging, veilige connectie, etc. Dit is vastgelegd in het XDS convenant en aansluitdocument. De MyChart optie is vergelijkbaar, echter niet geborgd door IHE profielen maar door een Veilige Infrastructuur Architectuur. Het SAML token kan hier aangenomen worden door Amphia om de veilige sessie naar Amphia door te trekken. Deze gegevens kunne ook gebruikt worden voor Single Sign On. Doordat Amphia de gegevens in eerste instantie verstrekt, kan er ook eenvoudig intern autorisaties uitgegeven worden op de beschikbare gegevens. Dit zal via een tussenstop gaan. De patiënt raadpleegt een server (MyChart) en deze server haalt op EPIC alleen de gegevens waar de gebruiker bevoegd voor is en koppelt deze terug naar de MyChart server, waar de presentatie plaats vindt. Wanneer het geen patiënt is (geïdentificeerd via BSN) maar een zorg verlener (BSN + GBA) zal de identificatie en autorisatie stringenter worden ingeregeld. Een zorg verlener kan meerdere patiënten in zien. De gehele opbouw is encrypt op hige standaarden, toegang verkrijgen tot identiteit is minimaal en om autorisaties van buitenaf te regelen is onmogelijk. Daarmee blijven twee punten openstaan: technisch en social enginering. Technisch houd in dat er
Molengracht, Breda Van Datum Onderwerp Pagina
Ulco Woudstra 14 augustus 2014 Globaal technisch ontwerp POC 7/10 middelen moeten zijn op updates in te kunnen regelen, security software inregelen en de controle dat alles is ingeregeld (bv NAC, perimeter firewalls, audits, etc). Dit is te realiseren. Dan blijft onjuist gebruik van de personen het grootste risico. De patiënten laptop is toegankelijk, intern worden de juiste procedures niet gevolgd, mensen zijn te manipuleren om (onbewust) gegevens te verstrekken etc. Dit dient door awareness en herhaalde herinnering duidelijk gemaakt te worden. In de lijn die we nu opzetten is de veiligheid ingeregeld. Het is gebaseerd op een vertrouwen tussen een aantal partijen, waaronder Meddex, Amphia en de UPZuid Community. Ook de patiënt en hulpverlener mogen we hier niet vergeten.
5.
Flow voor de patiënt en de zorgverlener
Voor de patiënt: 1) Patiënt logt in op Meddex (via username, password en sms) 2) Op het Meddex scherm krijgt de patiënt het aanbod van de volgende gegevens: a.
NAW gegevens
b.
Optie om Beelden en verslagen (vanuit XDS registry) in te zien. Dit is standaard XDS consumer functionaliteit.
c.
Optie om BPPC te wijzigen. Op de achtergrond wordt door Meddex uitgevoerd wat beschreven staat in paragraaf 1.4.
3) Optie om naar overige gegevens te gaan (Mychart via site2site verbinding tussen Meddex rekencentrum en Amphia) en geef BSN nummer mee. Als patiënt stopt, dan komt deze terug in scherm 2. Voor de zorgverlener: hetzelfde als voor de patiënt met de volgende verschillen: Zorgverlener gaat naar Carelink i.p.v. Mychart (en krijgt de AGB code mee (naast Amphia patient nummer)).
Molengracht, Breda Van Datum Onderwerp Pagina
Ulco Woudstra 14 augustus 2014 Globaal technisch ontwerp POC 8/10
Bijlage 1: POC beslisdocument (Jelmer Kranenburg) Bijlage 2: Infrastructuur ontwerp (Edwin Groenewegen) Bijlage 3: Publiceren van gegevens aan externen (Edwin Groenewegen) Bijlage 4: Beschrijving van de claimbased authenticatie In onderstaande figuur 3 wordt het proces van claimbased authenticatie (uit bijlage 3) beschreven. Vanuit Epic wordt een “tijdelijke AD” (SQL database) opgebouwd met 16 data elementen per patiënt (Zie 1.3). Deze patiënten zijn niet bekend in de Amphia AD. De externe zorgverleners hoeven niet bekend te zijn in de Amphia AD. Meddex doet de identificatie/autorisatie van de patiënten, die aanmelden bij het patiënt portal. Ook doet Meddex de identificatie/autorisatie van de zorgverleners die aanmelden bij het patiënt portaal. Als de patiënt verder wil naar Mychart, dan wordt door Meddex een SAML token (met BSN nummer) gestuurd naar Amphia. Deze wordt gecontroleerd door de Firewall en gaat daarna door naar de UAG. De UAG (uitgebreid met ADFS server) checkt het SAML token (BSN patient): Als BSN patiënt in tijdelijke AD (patient) dan toegang Mychart OK. Als een externe zorgverlener verder wil naar Carelink, dan wordt door Meddex een SAML token (met BSN patiënt en AGB code zorgverlener) gestuurd naar Amphia. Deze wordt gecontroleerd door de Firewall en gaat daarna door naar de UAG. De UAG (uitgebreid met ADFS server) checkt het SAML token (BSN patient): Als BSN patiënt in tijdelijke AD (patient) dan toegang tot Carelink OK. Er wordt dus geen verificatie gedaan van de AGB code van de zorgverlener. Door de UAG/Federation server/Radius server vindt een “verrijking” plaats van het SAML token (d.w.z. het Amphia patientnummer wordt meegenomen uit de “tijdelijke AD”) op basis waarvan URL’s kunnen worden opgesteld. Als toegang Mychart OK dan wordt een URL geopend naar Mychart (met Amphia patientnummer). Als toegang Carelink OK dan wordt een URL geopend naar Carelink (met Amphia patientnummer en AGB code zorgverlener).
Molengracht, Breda Van Datum Onderwerp Pagina
Ulco Woudstra 14 augustus 2014 Globaal technisch ontwerp POC 9/10 In figuur 3 wordt onderscheid gemaakt tussen productie (P) en testomgeving (T) voor - Mychart/Carelink en de onderliggende Epic database - Meddex - XDS De UAG, de ADFS server, de SQL database (“tijdelijke AD”) en de Meddex extractie programmatuur zijn enkelvoudig uitgevoerd. Dat betekent dat dit eerst wordt gebruikt in de T-omgeving en daarna wordt overgezet naar de P-omgeving.
Amphia Applicatie
Authenticatie
Meddex Applicatie
Software lokaal
Software
Software
XDS registry
Mychart / Carelin
Meddex P
XDS P
Mychart / Carelin
Meddex T
XDS T
UAG ADFS Server Epic DB P Epic DB T
SQL databas e Meddex extract ie
Figuur 3: Functionele weergave van claim based authenticatie
Molengracht, Breda Van Datum Onderwerp Pagina
Ulco Woudstra 14 augustus 2014 Globaal technisch ontwerp POC 10/10 In de uitwerking door Patrick Koevoets Brainforce van de UAG functie wordt een Microsoft Federation server toegevoegd die de communicatie verzorgt van de UAG naar de tijdelijke AD (SQL database). Hieronder is een beschrijving van het complete federation proces voor MyChart/ Carelink ( punt 1 t/m 4 kan afwijken dit is volgens het officiële federation proces) 1) De gebruiker gaat naar MyChart/CareLink 2) De gebruiker komt uit op de UAG server. 3) De UAG server ziet dat de gebruiker nog niet gevalideerd doormiddel van SAML en stuurt de gebruiker naar de federation Server van Amphia. 4) De federation server stuurt de gebruiker naar de Meddex federation server. 5) De gebruiker authentiseert en krijgt een SAML token van de Meddex federation server. 6) De Meddex federation server stuurt de gebruiker met het SAML token terug naar de federation server van Amphia. 7) De federation server van Amphia valideert de token. 8) De federation server verrijkt de SAML token met informatie uit de bron systemen (SQL server) van Amphia 9) De federation server van Amphia stuurt de gebruiker met de aangepast SAML token terug naar de UAG server. 10) De UAG server ziet dat de gebruiker een token heeft en accepteert de aangepast SAML token. 11) De SAML token wordt gelezen door transformatie service en vertaalt deze naar een formaat voor de applicatie 12) De gebruiker wordt automatisch door gestuurd naar de applicatie en krijgt toegang.
Bovenstaande stappenplan gaat uit van onderstaande componenten aan Amphia zijde: •
Verrijking gegevens (SQL/AD)
•
Federation Server (ADFS)
•
Custom ruleset voor verrijking van gegevens binnen federation server.
•
UAG Server met meerdere portals (federation en applicatie(s))
•
Script voor post validatie of een SAML token vertaal service.
