Borgerkalender POC rapport

Transkript

1 Borgerkalender POC rapport POC borgerkalender Draft 17/

2 Indholdsfortegnelse Indhold Indholdsfortegnelse... 2 Om dokumentet... 2 Borgerkalender... 2 Vejledning i brug af POC... 3 Løsningsoversigt... 4 Sikkerhedsløsningen... 5 Persistering af aftaler... 6 Samtykke... 6 Performance og cachingstrategi... 7 Synlighed af aftaler... 7 Todo... 7 Om dokumentet Dette dokument indeholder, udover en vejledning i anvendelsen, en kort opsummering af de erfaringer POC projektet gav, de valg vi foretog og nogle anbefalinger til eventuel videreudvikling. Bemærk at sideløbende med denne POC udarbejder Alexandra Instituttet en rapport med anbefalinger til sikkerhedsløsninger. Den rapport har vi ikke haft adgang til, da den bliver udarbejdet sideløbende. Læseren bør derfor også læse den rapport og ikke blot denne POC rapport. Borgerkalender Udgangspunktet har været 2 scenarier og udsagnet nemhed i brug kontra sikkerhed, for at åbne for pragmatiske løsninger i POC en. Scenarie A: Simpelt aftalegrundlag kendskab til URL angiver aftalen Borger opretter adgang til egne data til sig selv. 1. Borger logger ind på selvbetjeningsløsning med NemID 2. Borger opretter kalender end-point og angiver synlighedsniveau 2

3 3. Borgeren selv (eller anden person) opsætter kalender på mobiltelefon til nyt end-point 4. Synkroniser kalender Scenarie B: Komplekst aftaleflow Borger giver adgang til sin nabo, så denne kan se borgeren aftaler med det offentlige. 1. Borger logger ind på selvbetjeningsløsning med NemID 2. Borger opretter aftale og distribuerer URL til aftale til anden part (nabo, pårørende etc) f.eks. via SMS 3. Anden part modtager aftaleendpoint fra borgeren 4. Anden part logger på selvbetjeningsløsning med NemID og godkender aftale, hvorved borger notificeres 5. Borger logger på og tjekker at den anden part er den, som aftalen var tiltænkt 6. Borger godkender aftale 7. Anden part genererer brugernavn og password og endpoint for borgerens kalender 8. Anden part opsætter kalender på mobiltelefon til nyt end-point og brugernavn/password 9. Synkroniser kalender Endelig har udgangspunktet for at afprøve netop en borgerkalender været nemhed i brug kontra sikkerhed, da ingen forventer at skulle logge ind hver eneste gang en kalender synkroniseres op mod en server. Vi har i denne POC valgt at implementere scenarie A. Vejledning i brug af POC Når man skal i gang med at bruge borgerkalenderen er det første, man skal gøre, at logge sig på selvbetjeningsløsningen. Denne er til rådighed på Det er kun afprøvet i Chrome browseren, men burde fungere generelt. Der skal oprettes en ny kalender URL (kalender end-point), hvilket gøres under menupunktet Mobiladgang til borgerkalender. Denne del af løsningen er beskyttet, så man redirectes til en loginside. Gyldige credentials er (theusername/thepassword). Efter succesfuld login redirectes tilbage til selvbetjeningsløsningen, hvor det nu er muligt at oprette én eller flere mobiladgange for den givne borger (bemærk CPR nummeret i øverste højre hjørne det er cpr nummer for den borger man er logget ind som). 3

4 En mobiladgang oprettes med et givent synlighedsniveau. I denne POC opereres med følgende: Eksistens: Man kan se, at der er en aftale på et givent tidspunkt, men ikke andre informationer Adresse: Man kan se, hvor aftalen skal foregå (LOCATION) Detaljeret: Man kan se al information på aftalen. I listen over mobiladgange ses den komplette URL, der skal bruges for at tilgå borgerkalenderen via mobiladgangen. Denne URL kopieres og indtastes i URL feltet for abonnementskalenderen i den kalenderløsning der anvendes. Vi har testet på iphone5 standard kalender og i Outlook. Til testformål er der blevet lavet et menupunkt Opret aftale som er en nem måde at oprette en ny aftale i borgerkalenderen. ÆØÅ virker ikke men det er ikke væsentligt for POC en. Løsningsoversigt Følgende tegning viser komponenterne, der udgør implementationen af POCen. Løsningsoversigt POC Løsningen forudsætter eksistensen af følgende komponenter: 1. Klientapplikation: Givet en smartphone med kalenderapplikation, skal der kunne sættes et kalenderabonnement op ved at oprette ny konfiguration bestående af URL til kalender. 2. XDS Registry og Repository: Til at opbevare de konkrete aftaler i en patientkalender anvendes et XDS Registry og Repository. 4

5 3. Identity Provider: Til autentificering af borgere (brugerne af selvbetjeningsløsningen). 4. Kalenderservice: Udstiller abonnementskalender på given URL. 5. Selvbetjeningsløsningen: GUI med funktionalitet til vedligeholdelsen af en borgers mobiladgange til kalender. Den følgende tegning viser, hvad der skal til, for at bringe POCen over i en tilstand, der dækker det i forgående afsnit beskrevne scenarie B: Løsningsoversigt to-be Sikkerhedslaget har fået tilføjet Basic Auth. Denne protokol understøttes af de fleste kalenderprogrammer og ville være et godt udgangspunkt for en kalenderservice. Ved at implementere dette scenarie er der også styr på identiteten af den kaldende klient idet der foregår et egentligt login og autentificering i forbindelse med kalendersynkroniseringer. Sikkerhedsløsningen Denne løsning består grundlæggende af to komponenter: Selvbetjeningsløsningen og selve kalenderløsningen. Selvbetjeningsløsningen er en web applikation, hvor det er muligt at oprette mobiladgange for en given borger. Sikkerheden for selvbetjeningsløsningen er baseret på SAML 2.0. Denne standard er også den, som NemLogin baserer sig på. Til denne POC har vi for nemheds skyld anvendt IdP (Identity Provider) SimpleSamlPhp. I forbindelse med driftsmodning, skal NemLogin anvendes i stedet for. Denne opgave er mest et spørgsmål om konfiguration og vurderes til at være af begrænset omfang. I denne POC udbydes selve kalenderløsningen som en abonnementskalender på en given (hemmelig) URL. Sikkerheden er således et spørgsmål om, at URL en skal forblive hemmelig. Dette er ikke godt nok, hvis der 5

6 er tale om at udbyde personfølsom information (som det kan være tilfældet med synlighedsniveauerne Adresse og Detaljeret), men muligvis OK i forbindelse med synlighedsniveauet Eksistens. Blandt andet for at forbedre sikkerhedsniveauet (samtykke og logning) bør man i forbindelse med en ibrugtagning omlægge kalenderløsningen til en standard, hvor autentificeringsmulighederne er af en tilstrækkelig sikker beskaffenhed (f.eks. brugernavn og password (niveau 2) som vedligeholdes gennem selvbetjeningsløsningen, som igen kræver NemID). Oprettelse af aftalegrundlag mellem borgeren og andre personer er beskrevet i scenarie B. SAML(1) på tegningen ovenfor: For at kunne tilbyde Basic Auth til kalenderapplikationer og evt. andre (mobile) klienter, skal der skabes en bro mellem Basic Auth udadtil og sikkerhedsarkitekturen indadtil, der baserer sig på SAML (se også sikkerhedsrapport). Denne bro kan realiseres ved at skabe en ny sikkerhedskomponent, der både kan bruges til kalenderservicen, men også til lignende services, der ønskes udstillet til ikke-web klienter. Denne komponent bliver en implementation af SAML ECP (SAML Enhanced Client and Proxy) profilen. SAML(2) på tegningen ovenfor: Her veksler kalenderservicen SAML token til andet SAML (XUA) token via STS. Persistering af aftaler I denne POC gemmer og hentes aftaler i et EMC XDS Repository. Aftalerne repræsenteres i et XML format beskrevet her ( Disse XML dokumenter fremsøges og hentes i XDS en via standardhåndtagene ITI-18 og ITI-43. For at kunne skelne aftaler fra andre typer af dokumenter ledes efter dokumenter, der er registreret med event code Dette er LOINC kode of en opfølgningssamtale. Data kan ses i XDS via Documentums Administrator Client, der er tilgængelig på (adgang kan gives efter aftale). I forbindelse med en driftsmodning skal det overvejes, om denne strategi er den rette, eller om man f.eks. i stedet skal sigte efter at bruge FHIR Appointment services. Samtykke I nuværende POC giver samtykke ikke direkte mening, da borgeren blot giver sig selv adgang til data. Næste trin, at borgeren kan give adgang til andre borgere f.eks. via et aftaleflow kan man diskutere om stiller krav om en selvstændig samtykke service da borgeren selv vælger at dele data og også hvilken synlighedsgrad den anden bruger har på data. Det er først når delingen sker med medarbejdere at en decideret samtykke service kan komme i spil. I selv i den situation er det ikke sikkert det er nødvendigt, da samtykket kan være defineret af eksistensen af en aftale og hvilke rettigheder der ligger i aftalen, således at aftalen og indholdet af aftalen i sig selv danner et samtykke. Det bør undersøges nærmere hvorvidt en decideres samtykke service skal anvendes også når det er borgeren selv der vælger at dele data der er trukket ud af det underliggende XDS repository (en cache i det her tilfælde en kalenderservice) og i så fald hvilke krav det stiller til etableringen af aftalerne borgeren laver omkring adgang til sine egne data. 6

7 Performance og cachingstrategi De fleste kalenderprogrammer vil synkronisere med kalenderserveren med jævne mellemrum. I denne POC dannes abonnementskalenderen ved hver forespørgsel fra klienten. Dette er klart den enkleste tilgang, men kan i driftssituationen give problemer. Det kan være relevant at overveje, om der skal anlægges en cachingstrategi, og i så fald, hvor denne skal implementeres. Hvis der vælges en løsning, hvor der skydes en CalDAV server ind som en komponent i løsningen vil det være nærliggende, at lade denne agere cache for at forbedre performance, men også for at gøre løsningen mere stabil (XDS kan være nede, men løsningen stadig kører, da kalenderserver stadig er oppe). Ved at anvende CalDAV serveren som cache introducerer man to problemer, der skal tages hånd om: 1) Der sker ændringer i borgenens aftaler i XDS bag CalDAV serveren: Det skal være muligt at opsætte noget notifikation, således at CalDAV serveren ved, hvornår den skal danne den pågældende kalender på ny ud fra data i XDS. Mulighederne for notifikationer er muligvis specifikt for det repository, der vælges. 2) Der sker ændringer i borgerens aftaler: Der skal også være muligt at notificere CalDAV serveren om at gendanne en kalender, hvis der ændres i aftalerne for den pågældende borger. Synlighed af aftaler Det skal være muligt for borgeren at til/fravælge detaljer i aftalerne i kalenderen for at understrege nødvendigheden af at det f.eks. er borgerens eget ansvar at der er kalenderaftaler i kalenderen på hans/hendes mobiltelefon hvis den bliver stjålet. Default bør være laveste synlighedsniveau. Der er i princippet to typer aftaler: A) aftaler borgeren opretter i egen kalender evt. via andre systemer hvor han/hun kan selvbooke, men aftalen kommer aldrig over i den offentlig drevne borgerkalenderservice; B) aftaler der gemmes på den offentlig drevne borgerkalenderservice. I tilfælde A har borgeren naturligvis ret til at gemme hvad som helst på i sin kalender, men vi kan ikke gemme det på den centrale borgerkalenderservice uden at den overholder samme krav til databehandling som aftaler initieret via en offentlig service og gemt i den offentlig drevne kalenderservice. Vi har derfor valgt at sige at alle aftaler gemmes i kalenderservicen og dermed er underlagt samme krav til databeskyttelse. Vi har, som eksempel, valgt 3 niveauer af synlighed, som er implementeret som templates, dvs. de giver adgang til aftalte felter og resten sendes ikke fra XDS repository til kalenderservicen. Todo En ikke udtømmende liste over opgaver der skal løses for at kunne gå i produktion. Dataformat for kalender i XDS (FHIR anvendt i POC) o Herunder status for en aftale: accepteret, aflyst, slettet osv. 7

8 API til XDS kalenderdata (f.eks ITI/FHIR) Modellering af synlighed (hvor angives dette og hvilke niveauer giver adgang til hvilke data) Kode for aftaledokumenter (i POC er det en LOINC kode) Skal/må dokument id fra XDS databasen anvendes til aftale ID i kalenderservicen? Er det i det hele taget kun en borgerkalender eller skal sundhedsprofessionelle også have adgang? Mere generel aftalehåndering (scenarie B) Skal der kunne være en blanding af synlighedsniveauer, så en borger kan have detaljer på nogle aftaler og kun eksistens på andre? Det er tvivlsomt om det er anvendeligt/brugervenligt at sætte op plus det vil kræve typer/grupperingsmekanismer på de enkelte aftaler. Anvende NemLogin til validering af borgeren på selvbetjeningsløsningen Er det sikkert nok at anvende brugernavn/password til kalenderen, når det er brugeren selv der opretter den mobile adgang og logger ind med NemID når adgagen oprettes? Sammenhæng ml. samtykke og aftaler om deling af data skal undersøges. Ejerskab af de data borgeren har trukket ud i en cache bør undersøges f.eks. er det nu borgeren der ejer data og dermed har en række muligheder med disse data, som en offentlig organisation ikke har. Er data trukket ud i en cache udelukkende read-only eller må de f.eks. kvalificeres? 8