BIF Bastjänster för InformationsFörsörjning Tekniska specifikationer Version ett Maj 2007
|
|
- Nils Berg
- för 8 år sedan
- Visningar:
Transkript
1 BIF Bastjänster för InformationsFörsörjning Tekniska specifikationer Version ett Maj 2007
2 Bastjänster för InformationsFörsörjning BIF Teknisk specifikationer Version Ett Maj 2007 Maj
3 Innehållsförteckning 1.1 Termer Inledning Arbetsgång Förarbete till standard Läsanvisning Avgränsning Projektdeltagare BIF övergripande beskrivning Syfte med Bastjänster för InformationsFörsörjning Konceptuell beskrivning av tjänsterna Detaljerad beskrivning av IT-tjänsterna i BIF Användningsfall Generella funktionella krav Generella icke-funktionella krav Grundläggande beståndsdelar Generella behov IT-tjänst för autentisering Tjänstespecifikation: Autentisering Syfte med tjänsten Konceptuell beskrivning av tjänsten Avgränsning Funktionella krav Tjänstegränssnitt: Funktioner Autentisering för Webapplikationer Stöd för autentisering med verksamhetsuppdrag och/eller syfte Agent IT-tjänst för Åtkomstkontroll (ÅKT) Tjänstespecifikation: ÅKT Syfte med tjänsten Konceptuell beskrivning av tjänsten Avgränsning Funktionella krav Tjänstegränssnitt: Funktioner XACML protokollens användning i BIF åtkomstkontroll IT-tjänst för Samtycke Tjänstespecifikation: Samtycke Syfte med tjänsten Maj
4 6.3 Konceptuell beskrivning Funktionella krav Tjänstegränssnitt: Funktioner Åtkomstkontrollstjänstens användning av samtyckestjänsten IT-tjänst för Vårdrelation Tjänstespecifikation: Vårdrelation Syfte med tjänsten Konceptuell beskrivning av tjänsten Funktionella krav Tjänstegränssnitt: Funktioner Åtkomstkontrollstjänstens användning av vårdrelationstjänsten IT-tjänst för Utlämnande Tjänstespecifikation: Utlämnandetjänst Syfte med tjänsten Konceptuell beskrivning av tjänsten Funktionella krav Tjänstegränssnitt: Funktioner IT-tjänst för Säker patientkontext Tjänstespecifikation: Säker patientkontexttjänst Syfte med tjänsten Konceptuell beskrivning av tjänsten Avgränsning Funktionella krav Tjänstegränssnitt: Funktioner Standard Kontexttopics Kontexthantering för Webapplikationer Tjänsteagent IT-tjänst för Notifiering Tjänstespecifikation: Notifiering Syfte med tjänsten Konceptuell beskrivning av tjänsten Administrationsgränssnitt Avgränsning Funktionella krav Tjänstegränssnitt Teknisk beskrivning IT-tjänst för Loggning Maj
5 11.1 Tjänstespecifikation: Loggtjänst Syfte med tjänsten Konceptuell beskrivning av tjänsten Avgränsning Funktionella krav Tjänstegränssnitt: Funktioner Loggdata Icke-funktionella krav Tjänsteagent Agentens gränssnitt: funktioner IT-tjänst för Logganalys Tjänstespecifikation: Logganalys Syfte med tjänsten Konceptuell beskrivning av tjänsten Avgränsning Funktionella krav Tjänstegränssnitt: Funktioner Tjänsteagent Övriga specifikationer Resursmodell Typer av åtkomstkontroll Egenskaper och rättigheter Biljettbeskrivning SAML SAML biljettens användning Användning av biljetter i meddelanden BIF Implementering Inledning Grundförutsättningar Grundimplementering Scenario I Migration Inkapsling Referenser Förändringar jämfört med BIF Slutrapport 0.95 B Generellt Autentiseringstjänsten Maj
6 17.3 ÅKT Vårdrelationstjänsten Samtyckestjänsten Utlämnandetjänsten Säker Patientkontexttjänsten Loggtjänsten Logganalystjänsten Notifieringstjänst Resursmodell, egenskaper och regler Implementering Maj
7 1.1 Termer Term Aktör Användare Autentisering Behörighet BKS CA Certifikat Egenskaper e-id kort Elektronisk katalog e-underskrift HCC HSA HSA-ID HSA-katalog IT-tjänst Kaskadering Kedjad loggning Loggning Beskrivning Person eller IT-tjänst som utnyttjar IT-tjänst. Eng. Subject I denna rapport: person som utnyttjar IT-tjänst. Snävare term än aktör. Fastställande av en användares identitet. Har ofta utförts enbart med användarnamn/nummer, men i BIF ställs krav på elektronisk autentisering enligt SITHS med HCC. Utförs av autentiseringstjänsten och är en förutsättning för åtkomstkontroll och loggning. Vanlig benämning på en aktörs rättigheter (se rättigheter) Behörighetskontrollsystem: Vanlig benämning på funktionalitet i stuprörsliknande system som hanterar flera aspekter av informationssäkerhet (användarnamn, lösenord, roller, rättighet etc). I denna rapport används termen rättighet och Åtkomstkonbtroll för att markera skillnaden gentemot tidigare uppbyggnad. Certification Authority; organisation som utfärdar certifikat genom att signera certifikat med sin privata CA-nyckel. På svenska: certifikatsutfärdare. Ett av en CA elektroniskt signerat intyg som knyter en publik nyckel till en specifik nyckelinnehavare. Kännetecken på användare, aktivitet eller resurs (vårdinformation). I IT-sammanhang ofta benämnt attribut Elektroniskt ID-kort; så kallat smart card, innehållande processor. eid-kortet är bärare av innehavarens privata nycklar och skyddat av dennes personliga kod. Databas, ofta hierarkisk, innehållande information om egenskaper hos objekt, t.ex. individer, organisationer, hårdvara. En form av elektronisk signatur som skapas genom att signatären signerar digital information med den av sina två privata nyckel som är avsedda för detta enligt en speciell procedur. HealthCare Certificate = Hälso- och sjukvårds Certifikat, certifikat för svensk vård och omsorg enligt SITHS-modellen. Hälso- och sjukvårdens adressregister Sverigeunikt id som identifierar en vårdgivare. Elektronisk katalog organiserad enligt HSA-modellen. Specialiserad producent som tar emot order från konsumenter och leverera tillbaka begärda resultat. Verkar i SOA-miljö. En tjänst anropar en tjänst, som i sin tur anropar en annan tjänst osv, osv, osv På teknisk väg säkra loggar mot radering. Registrering av aktiviteter utförda av aktör, med syfte till att uppnå spårbarhet i aktiviteter avseende vårdinformation. Maj
8 Menprövning Objekt Omgivningsfaktor PDP PEP PersonId Privat nyckel Publik nyckel Regelverk Resurs RIV Rättighet Rättighetsregel SAML Samtycke SDK Sekretess Sekretessområde En skadeprövning görs och det står klart att utlämnande av vårdinformation kan ske utan att den enskilde eller dennes närstående lider men. Se Resurs En uppsättning egenskaper som används av regelsystemet för att tillsammans med aktörs-, resurs- och aktivitetsegenskaper evaluera beslut. Med omgivningsfaktorerna kan en IT-tjänst förmedla egenskaper som rör den miljö och omgivning ur vilken resurserna hämtas. Policy Decision Point Policy Enforcement Point Personnummer, samordningsnummer eller reservnummer. Den privata delen av ett nyckelpar som används inom asymmetrisk kryptering. Den privata nyckeln används främst för att skapa digitala signaturer samt för dekryptering av krypterad information. Den publika delen av ett nyckelpar som används inom asymmetrisk kryptering. Den publika nyckeln används främst för att verifiera digitala signaturer samt för att kryptera information. Alla juridiska och verksamhets regler. Generisk term för tillgång som ska åtkomstskyddas (vårdinformation, skrivare etc). Regelverk för elektronisk Interoperabilitet inom Vård och omsorg Vilken/vilka aktiviteter en aktör tillåts utföra med en resurs Enskild regel som ingår i ett regelverk. Security Assertion Markup Language Xml-standard för utbyte av autentisering, attribute mm. I texten refereras till version 2.0 Patienten har rätt att efterge sekretessen dvs hon/han kan ge sitt samtycke till att viss eller all vårdinformation lämnas ut. Samtycket kan vara skriftligt eller muntligt. I vissa fall är det inte möjligt att få samtycke. Detta kan då vara underförstått, s k presumtivt samtycke. Software Development Kit, programmatiskt utvecklingspaket innehållande programfunktioner för åtkomst till intern funktionalitet och ofta en uppsättning hjälpfunktioner. lagstadgat förbud att röja uppgift Sekretesslagen (1980:100) anger vad som är sekretessbelagt och därmed undantaget från regeln att myndigheternas allmänna handlingar är offentliga. Sekretess innebär både förbud att röja en uppgift muntligt eller på annat sätt och förbud att lämna ut allmänna handlingar och gäller skydd för enskilds hälsotillstånd och andra personliga förhållanden. Enligt sekretesslagen råder sekretess mellan myndigheter och mellan olika verksamhetsgrenar inom samma myndighet - sekretessområden. Sekretesslagen gäller för uppgiftslämnande till dem som finns utanför myndigheten yttre sekretess. Maj
9 SITHS SOA Subjekt Temporär Underteckna elektronisk Utlämnade Utlämnande Inom en myndighet/verksamhetsgren gäller inre sekretess. Så kallad inre sekretess är inte beskrivet i sekretesslagen, men är indirekt beskrivet i bl.a. Patientjournallagen (sekretess om ej behov och vårdrelation), Säker IT i Hälso- och Sjukvården. Projekt som resulterade i den s.k. SITHS-modellen för informationssäkerhet inom hälso- och sjukvården. Tjänstebaserad arkitektur (Service Oriented Architechture) Principerna för en tjänstebaserad arkitektur kan beskrivas i följande punkter: Tjänsteleverantörer utför tjänster åt tjänstekonsumenter Tjänsterna som utförs definieras av meddelanden vars uppbyggnad publiceras Tjänstekonsumenterna hittar tjänsteleverantörerna via tjänstemäklare Tjänstekonsumenter och tjänsteleverantörer är löst kopplade till varandra, d.v.s. förbindelse mellan tjänstekonsument och tjänsteleverantör upprätthålls endast mellan anrop och avgivet svar (fysiskt lös koppling i runtime) Tjänsteleverantörerna är tillståndslösa mellan anrop, d.v.s. bevarar inte sessionstillstånd hos tidigare anrop från tjänstekonsumenter. Verksamhetsbundna status och tillstånd lagras däremot i de underliggande system som tjänsteleverantören nyttjar (logiskt lös koppling i runtime) Den inre tekniska uppbyggnaden hos tjänstekonsument eller tjänsteleverantör avspeglas inte i meddelanden eller i tjänsteleverantörernas tekniska gränssnitt (lös koppling vid design) Tjänsteleverantörerna är självständiga mot sina konsumenter, d v s ansvarar för funktionella och icke-funktionella egenskaper (säkerhet, spårbarhet, validering, versionshantering mm) Den tjänstebaserade arkitekturen säger däremot ingenting om val av teknik. Se vidare Carelink PLUS och RIV Se aktör Tidsbegränsad Se e-underskrift Begrepp som i text innebär att information flyttas till den som frågar om den I denna rapport används termen utlämnande huvudsakligen i betydelsen av den skadeprövning som görs enligt sekretesslagen (menprövning), när samtycke saknas. Maj
10 Vårdinformation Vårdrelation Vårdtjänst XACML Åtkomstkontroll Både vid applicering av samtycke och menprövning, sker i bägge fallen ett utlämnande dvs vårdinformation överförs över en sekretessgräns. Detta registreras automatiskt i loggen och är därför underförstått i denna rapports beskrivningar. All information om patienten i vården. En hälso- och sjukvårdspersonal har en vårdrelation om han/hon deltar i planering, utförande och/eller uppföljning av patientens vård Andra IT-tjänster än BIF-tjänster extensible Access Control Markup Language En typ av rättighetskontroll som reglerar åtkomsten till en specifik aktivitet eller resurs (vårdinformation). Sker i Åtkomstkontrolltjänsten. Maj
11 2 Inledning BIF-projektet initierades 2006 av de tre storregionerna och innebar att man i samverkan mellan flera regioner/landsting överenskom om en gemensam syn på funktionalitet och teknikval för framtida säkerhetstjänster i en tjänsteorienterad arkitektur. Resultatet publicerades i en slutrapport i två delar, 0.95 A och B. I slutrapport A gavs en övergripande beskrivning till BIF med introduktion, projektstruktur och funktionell beskrivning. I del B gavs tekniska specifikationer till en viss nivå. Från 2007 är BIF ett nationellt projekt under Beställarfunktionen på SKLs ansvar och genomförs i Carelinks regi. Hittills har tre delprojekt avlämnat delresultat: Affärsmodell, Test/Certifiering och Förarbete till standard. Det är det sistnämnda som är denna redovisning. Målet har varit att uppnå informationssäkerhetsinteroperabilitet genom att definiera en teknisk norm i en första version, som i utnyttjande kan uppnå status av de facto standard. Denna uppsättning BIF-tjänster i sin första version, ska sedan med ökande krav kunna förädlas. 2.1 Arbetsgång Förarbete till standard Föreliggande rapport är en vidarebearbetning av Slutrapport 0.95 B. Bearbetningen har skett i en samfälld process mellan teknisk experter från landsting/regioner och leverantörer. Detta har skett i gemensamma arbetsseminarier, via telefonmöten och via . Processen har hela tiden varit öppen och delresultat av arbetet har funnits tillgängligt på Carelinks hemsida för synpunkter. Resultatet består huvudsakligen i en skärpning av tjänstebeskrivningarna. Uppskärpningen har dels varit en precisering av funktionella krav, dels en precisering av funktioner och gränssnitt (WSDL). Vidare har användningen av BIF-tjänsterna förtydligats med fler exempel. För att uppnå målet, har i vissa fall preciseringen av BIF-tjänsterna givit en anpassning av funktionalitet jämfört med tidigare beskrivningar. Detta har varit nödvändigt, då ursprungliga krav varit ofullständigt penetrerade och därmed för omfattande. Grundkonceptet från rapport 0.95 är dock oförändrat. 2.2 Läsanvisning För en introduktion till BIF avseende syfte, mål och konceptuell modell, hänvisas till BIF slutrapport 0.95 A, tillgänglig via Carelinks hemsida ( En detaljerad redogörelse för de förändringar som gjorts jämfört med Slutrapport 0.95 B ges i sista avsnittet. Här ges endast en översiktlig genomgång av innehållet. Rapporten inleds med översiktliga beskrivningar av funktionaliteten hos BIF-tjänsterna, med gradvis stigande komplexitet. De inledande, översiktliga beskrivningarna åskådliggör bland annat utnyttjandet av BIF inom och mellan organisationer. Därefter följer detaljerade användningsfall som beskriver tillämpningen av BIF-tjänsterna i ett verksamhetsscenario. Sedan följer en kort översikt av grundläggande beståndsdelar och en översiktlig beskrivning av en del av de generella behov som finns i en SOA-värld. Huvudparten av rapporten utgörs av de tekniska specifikationerna för varje enskild tjänst, med en detaljerad beskrivning av syfte, koncept, funktionella krav och funktioner. I en separat bilaga finns WSDL för alla tjänster. I rapportens avslutande del finns beskrivning av ingående resurs- och behörighetsmodell, och vilka oundgängliga egenskaper, som skall utnyttjas i regelverket. Här finns också detaljerad beskrivning av biljettens användning och SAML. Ett scenario för implementering av BIFtjänster har tillfogats. Maj
12 Denna rapport versionssätter IT-tjänsterna inom BIF till version 1.0 och avsikten är att tjänsterna med tiden kan utvecklas och därmed versionshanteras i en här för avsedd förvaltning. 2.3 Avgränsning De tekniska beskrivningarna innefattar inte nätverksoperativsystem. Klienthårdvara med kortläsare och tillhörande mjukvara beskrivs ej heller. Den övergripande säkerheten avseende kodsäkerhet, skydd mot attacker etc behandlas ej här. För ett införande av BIF-tjänster i en SOA-värld fordras också tjänsteförmedlare och tjänsteregister på olika nivåer, vilket är ett generellt behov och ej specifikt för BIF. En kort översikt finns dock i avsnitt Projektdeltagare Anders Beckman Region Skåne Projektledare Per Torlöf Region Skåne Stefan Holmberg Västra Götalandsregionen Yngve Svahn Örebro Läns Landsting Ted Wigefeldt Gaupe AB Lars Wahlgren Sentensia Q AB Torbjörn Dahlin Brainpool Henrik Båkman HP Henrik J Johansson Nexus Daniel Rodrigues Generic Magnus Vallstedt Microsoft Göran Melvås WM-data Martin Elwin Oracle Pontus Lindqvist/Benedikt Furrer IBM Dessutom har följande medverkat genom att kontinuerligt ge synpunkter på arbetsdokumenten: Ulf Palmgren SLL Anders Norr LiÖ Anders Lindberg Strategi AB Maj
13 3 BIF övergripande beskrivning 3.1 Syfte med Bastjänster för InformationsFörsörjning Syftet med BIF-tjänsterna är att på ett enhetligt sätt säkerställa den funktionella informationssäkerheten avseende IT-tjänsters hantering av vårdinformation inom hälso- och sjukvården, såväl inom som mellan organisationer. Syftet med denna inledande och övergripande beskrivning är dels att ge en helhetsbild, dels att ge utrymme för gemensam kravställning för BIF-tjänsterna kring teknik, standarder, dokumentation och andra icke-funktionella krav. 3.2 Konceptuell beskrivning av tjänsterna IT-tjänsterna i BIF samverkar i en tjänsteorienterad arkitektur (SOA) för att stödja informationssäker elektronisk hantering av vårdinformation. IT-tjänsterna har var för sig unik funktionalitet, men det erfordras full samverkan BIF-tjänsterna emellan för att informationssäkerhet skall uppnås avseende: Tillgänglighet Åtkomlighet för behöriga Skydd för obehörig insyn Riktighet/oförvanskad Spårbarhet och oavvislighet Följande IT-tjänster är beskrivna i BIF: Autentisering Åtkomstkontroll Vårdrelation Samtycke Säker patientkontext Loggning Logganalys Notifiering Utlämnande IT-tjänsten Åtkomstkontroll kan vid behov efterfråga underlag till beslut hos IT-tjänsterna Vårdrelation, Samtyckes och Utlämnande (se figur 1). Delar av funktionaliteten för vissa IT-tjänster finns i agenter, som är inkorporerade i en fasad. Agentens uppgift är att effektivisera IT-tjänstens funktion med för tjänstekonsumenten lokal bearbetning. Effektiviseringen kan ske med varierande grad av funktionalitet i agenten. Agenterna och fasaden är dock i detta dokument ej lika strikt standardiserade som själva ITtjänsterna. Behovet av agenter är starkt, men bedömningen är att utbytbarheten är viktigast för själva BIF-tjänsterna och att olika leverantörer kommer att tillverka/leverera olika SDK för respektive miljö. Maj
14 Figur 1 Samband BIF-tjänster 3.2.1Funktion och generalitet i BIF-tjänster Genom att funktionerna i BIF-tjänsterna är generiskt uppbyggda, hanteras all begäran om aktivitet (läsa, skriva etc.) på samma sätt i alla organisationer och det är de specifika reglerna som läggs in BIF-tjänsterna som styr detta. Det innebär exempelvis att en aktör endast behöver autentisera sig en gång, oavsett var han eller hon sedan söker vårdinformation Basal BIF-funktion inom en organisation Vid begäran om tillgång till vårdinformation är förenklat den övergripande händelsekedjan enligt följande: Aktören identifierar sig och erhåller biljett med certifikat och egenskaper. Därefter begär aktören tillgång till vårdinformation i en vårdtjänst. Vårdtjänsten kontrollerar då rättigheterna i Åtkomstkontrolltjänsten och aktören erhåller eller erhåller inte tillgång till vårdinformation. Alla aktiviteter loggas. Ett förenklat, schematiskt förlopp av funktionaliteten inom en organisation visas i figur 2: Maj
15 Figur 2 Schematisk förlopp i BIF-tjänsterna inom en organisation 1. Aktören presenterar sitt eid-kort och sin PIN-kod på sin arbetsplats. 2. Aktörens identitet och egenskaper verifieras i Autentiseringstjänsten. 3. Aktörens identitet och egenskaper skickas i Biljett till arbetsplatsen. 4. Med Biljetten begär aktören tillgång till vårdinformation i en IT-tjänst (vårdtjänst). 5. Aktörens och resursens (vårdinformationens) identitet och egenskaper kontrolleras mot regelverket i Åtkomstkontrolltjänsten. 6. Beslut om tillgång eller nekande lämnas till IT-tjänsten. 7. Resultat i form av tillgång eller nekande lämnas av IT-tjänsten till aktören. 8. Alla aktiviteter loggas (enbart illustrerat med loggning från IT-tjänst här) Basal BIF-funktion mellan organisationer När en aktör begär tillgång till information över en organisationsgräns blir förfarandet det samma, med den skillnaden att åtkomstkontrollen sker i den organisation som ansvarar för resursen/vårdinformationen, se figur 3. Det är aktörens egen organisationen som ansvarar för autentiseringen, men åtkomstbeslutet fattas av organisationen som ansvarar för vårdinformationen som via sitt egna regelverk. Förloppet illustreras förenklat i figur 3. Maj
16 Figur 3Schematisk förlopp i BIF-tjänsterna mellan två organisationer 1. Aktören presenterar sitt eid-kort och sin PIN-kod på sin arbetsplats. 2. Aktörens identitet och egenskaper verifieras i Autentiseringstjänsten, tillhörande aktörens organisation. 3. Aktörens identitet och egenskaper skickas i Biljett till arbetsplatsen. 4. Med Biljetten begär aktören tillgång till vårdinformation i en extern IT-tjänst (vårdtjänst). 5. Aktörens och resursens (vårdinformationens) identitet och egenskaper kontrolleras mot regelverket i Åtkomstkontrolltjänsten i den externa organisationen. 5 b Åtkomstkontrolltjänsten efterfrågar vid behov underlag från Samtyckes- och/eller Utlämnandetjänsten. 6. Beslut om tillgång eller nekande lämnas till IT-tjänsten. 7. Resultat i form av tillgång eller nekande lämnas av IT-tjänsten till aktören. 8. Alla aktiviteter loggas (enbart illustrerat med loggning från IT-tjänst här). 3.3 Detaljerad beskrivning av IT-tjänsterna i BIF Sekvens inom en organisation Aktörens identitet säkerställs med Autentiseringstjänsten. Denna funktion är beroende av en säker hantering av aktörens identitet och egenskaper, förutom certifikatshanteringen enligt SITHS. När användaren begär tillgång till vårdinformation, kontrolleras rättigheter i Åtkomstkontrolltjänst, som i sin tur kan efterfråga underlag i Vårdrelationstjänsten, Maj
17 Samtyckestjänsten och/eller Utlämnandetjänsten, samt vid behov begära fler egenskaper för aktören från Autentiseringstjänsten. För att undvika förväxling av patientinformation vid val av ny patient, synkroniseras alla aktiva vårdapplikationer med hjälp av Säker patientkontexttjänsten. Alla aktiviteter loggas och placeras i Loggtjänsten, där de följs upp med Logganalystjänsten. Förloppet (förutom Säker patientkontexttjänsten), är illustrerat med sekvensdiagram i figur 4. Figur 4 Sekvensdiagram intern rättighetshantering Sekvens mellan organisationer För tillgång till vårdinformation över organisationsgränser, utnyttjas att aktören är autentiserad på överenskommet sätt i sin egen organisation och ny autentisering behöver inte göras. Åtkomstregler styr om aktören får tillgång till vårdinformation genom samtycke eller prövning av behörigt utlämnande (menprövning). Begäran om tillgång till vårdinformation i annan organisation kan initieras på olika sätt: En egen vårdtjänst kan indikera att vårdinformation finns (utan att ange källa), en specifik ITtjänst kan indikera vårdinformation utanför egen organisation och aktören kan direkt begära vårdinformation i en annan organisations vårdtjänst. Om samtycke eller utlämnandebeslut finns, får aktören tillgång till vårdinformation, i annat fall blir det ett två-stegsförfarande: Oavsett hur aktören begär tillgång till vårdinformation i en annan organisation, sker alltid kontroll av rättigheter i ÅKT. Regler har lagts in som styr tillgång till vårdinformation för aktör från annan organisation och dessa anger att samtycke eller utlämnandebeslut måste finnas. ÅKT kontrollerar då om underlag finns i Samtyckestjänst respektive Utlämnandetjänst. Om inget underlag finns för till gång till vårdinformation, blir aktören nekad tillgång, men får samtidigt besked på varför han eller hon nekas. Aktören kan då välja att få samtycke från patienten (i dagens regelverk) eller att göra en begäran om utlämnande direkt i Utlämnandetjänsten hos den andra organisationen. (Ingen automatisk begäran om utlämnande sker från ÅKT.) Utlämnandetjänsten meddelar ansvarig Maj
18 prövare, så att menprövning kan ske. När prövning gjorts, meddelas aktören resultatet via Notifieringstjänsten. Den andra organisationens ÅKT efterfrågar utlämnandebeslut och ger därefter aktören rättighet till begärd vårdinformation. Denna åtkomst innebär att vårdinformationen överförs till aktörens egen organisation, för vidare hantering, figur 5. Figur 5 Sekvensdiagram för utlämnande mellan organisationer (Loggtjänst utelämnad) Maj
19 3.4 Användningsfall Dessa användningsfall visar utnyttjandet av samtliga BIF-tjänster Förutsättning Varje organisation har ett eget ansvar för aktörernas identitet och tillgång till resurser ( journal ). Det betyder att varje organisation själv logiskt måste hantera autentisering, åtkomstkontroll mm, men rent tekniskt kan detta lösas med gemensamma IT-tjänster Vårdinformation inom eget sekretessområde Doktor A i Landstinget A har träffat patienten Nils Nilsson och skall skriva en journalanteckning och ordinera läkemedel för rosfeber. Vid datorn på sin expedition identifierar Dr A sig via Autentiseringstjänsten med sitt e-id kort och dess PIN-kod. Han får då tillgång till en vårdtjänst. Han anger där patientens personnummer och via Åtkomstkontrolltjänsten (ÅKT) får han möjlighet att skriva ny text. Han för in aktuella observationer. (Figur 6 överst) Dr A ska därefter ordinera läkemedel. Förnyad kontroll (osynligt för användaren) i Åtkomstkontrolltjänsten ger honom tillträde till en läkemedelstjänst, utan att ny inloggning behöver göras dvs det blir en funktionell single-sign-on (SSO). Genom Säker Patientkontexttjänsten aktiveras automatiskt aktuell patient i Läkemedelstjänsten. Dr A ordinerar läkemedlet, undertecknar receptet elektroniskt och aktiverar säker e-förmedling av receptet. (Figur 6 un)derst In- och utloggningen, och allt Dr A läst och gjort däremellan, loggas till Loggtjänsten. Maj
20 Figur 6 Schematisk framställning av flöde i BIF - Vårdinformation inom eget sekretessområde. Grönt markerar aktiva BIF-tjänster, grått odefinierade tjänster Vårdinformation mellan landsting med samtycke Doktor B på ett sjukhus i Landstinget B träffar patienten Nils Nilsson efter dennes hemkomst från Lanstinget A. I Landstinget A har Nils Nilsson fått läkemedel e-förmedlat till Apoteket, men kan inte riktigt redogöra för omständigheterna kring det besöket. Dr B ber om Nils Nilssons tillstånd att läsa vårdinformation i Landstinget A och får det - erhåller Samtycke. Vid datorn på sin expedition identifierar Dr B sig via Autentiseringstjänsten med sitt e-id kort och dess PIN-kod. Han får då efter kontroll av Åtkomstkontrolltjänsten tillgång till Samtyckestjänst och Vårdrelationstjänst och kan där registrera patientens samtycke, respektive sin vårdrelation med denne. Dr B önskar sedan söka information i Landsting A, utanför sin egen organisation, vilket han i detta fall gör via en indextjänst. En (osynlig) kontroll görs i Åtkomstkontrolltjänsten och ger Dr B tillträde till indextjänsten, där aktuell patient automatiskt blir aktiverad med hjälp av Säker patientkontexttjänsten. Via indextjänsten begär Dr B vårdinformation i Landstingets As Vårdtjänst om Nils Nilsson. Begäran kontrolleras av regelverket i Lanstinget As Åtkomstkontrolltjänsts. Intyg om samtycke och vårdrelation har överförts med biljetten till Landsting A. Enligt Landstinget As regelverk tillåts läsning av journaltext av läkare och sjuksköterskor från Landstinget B om vårdrelation och samtycke föreligger och autentiseringen av användaren skett enligt lägsta överenskomna nivå, i det här fallet med e-id kort och PIN-kod. Därmed ges Dr B tillgång till vårdinformation. (Figur 7) Begäran om tillgång och beslut loggas i Loggtjänsten i Landstinget A. Dr B kan nu läsa aktuell journaltext. Läsningen registreras i Landstinget A som utlämnande av aktuellt avsnitt och loggas dessutom i Loggtjänsten. Efter läsning beslutar Dr B att aktuellt journalavsnitt från Landstinget A läggs in i den egna journaltexten, vilket noteras där. Dr B avslutar sin konsultation med Nils Nilsson. In- och utloggningen, och allt Dr B läst och gjort däremellan, loggas till Loggtjänsten i Landstinget B. Maj
21 Figur 7 Schematisk framställning av flöde i BIF - Vårdinformation mellan landsting med samtycke. Grönt markerar aktiva BIF-tjänster, grått odefinierade tjänster. Maj
22 3.4.4Vårdinformation mellan landsting med menprövning Dr A i Landstinget A får en ny patient Svea Sveasson, hemmahörande i Landstinget B. Svea Sveasson är på tillfälligt besök på sitt sommarställe, som ligger inom Landsting A. Hon bor där med sin son, som med hjälp av hemtjänst sköter henne. Nu är emellertid sonen på konferens och hemtjänstpersonalen har beställt tid för läkarundersökning. Dr A kan inte erhålla någon information från Svea Sveasson pga hennes sviktande mentala funktioner och därför inte heller något samtycke. Hemtjänstpersonalen kan inte bidra med annat än namn och vistelseadress. Tidigare sjukhistoria och eventuella läkemedel har endast sonen kunskap om, och han är inte tillgänglig. Vid datorn på sin expedition loggar Dr A in via Autentiseringstjänsten med sitt e-id kort och PIN-kod. Han anger patientens personnummer och via Åtkomstkontrolltjänsten får han möjlighet att registrera sin vårdrelation i Vårdrelationstjänsten, för att ha som underlag när han begär journalinformation från Sveas hemlandsting. Genom en (osynlig) kontroll i Åtkomstkontrolltjänsten får Dr A tillträde till indextjänsten, där aktuell patient via Säker patientkontexttjänsten blir aktiverad. Dr A anger där att han vill söka vårdinformation i Landstinget B (varifrån patienten kommer). Dr A ges nu möjlighet att efterfråga vårdinformation i Landstinget B via deras Utlämnandetjänst. I Utlämnandetjänsten i Landsting B noteras från Dr A s biljett 1 dennes identitet, organisationstillhörighet, verksamhetsområde, och att vårdrelation föreligger för aktuell patient. Dr A får en kvittens via Utlämnandetjänsten i Landstinget B att begäran om utlämnande av vårdinformation mottagits. Via Notifieringstjänsten i Landstinget B meddelas samtidigt jourhavande handläggare på Funktionen för Utlämnande i Landstinget B att prövning av behörigt utlämnande skall göras. Aktuell tjänsteman med rättighet att göra denna bedömning granskar begäran och fattar beslut om att utlämna definierat avsnitt. Beslut om utlämnande registreras i Utlämnandetjänsten. 2 (Figur 8) 1 Biljett=innehåller intyg om användarens egenskaper. Genom att elektroniskt underteckna biljetten garanterar utfärdaren dess innehåll. Biljett är en grundläggande komponent i SSO-funktionaliteten. Biljetten är utfärdad av en betrodd samarbetspartner. 2 All information rörande patienten räknas till patientjournalen, oavsett i vilken IT-tjänst den är registrerad. Maj
23 Figur 8 Schematisk framställning av flöde i BIF Begäran om utlämnande Dr A får via Notifieringstjänsterna i Landsting B och det egna Landsting A meddelande om att utlämnandebeslut är fattat. Dr A begär nu tillgång till aktuell vårdinformation via vårdtjänsten i Landstinget A. Åtkomstkontrolltjänsten i Landstinget B kontrollerar då i Samtyckestjänsten och Utlämnandetjänsten om underlag finns. Då det finns ett utlämnandebeslut, får Dr A tillgång till journaltexten. In- och utloggningen, och allt läkaren läst och gjort däremellan, loggas till respektive landstings Loggtjänst.(Figur 9) Maj
24 Figur 9 Schematisk framställning av flöde i BIF - Tillgång till vårdinformation efter utlämnandebeslut Maj
25 3.5 Generella funktionella krav K 1 Tjänsterna skall vara skalbara vertikalt och horisontellt 3. K 2 Tjänsterna skall ha grafiskt administrationsgränssnitt. K 3 Tjänsterna skall utformas så att de klarar 7:24 drift. K 4 Felhantering Om fel inträffar skall felsituationen hanteras så att information som beskriver felet kan loggas och rapporteras tillbaka till konsumenten. Felmeddelanden och felrapporter skall innehålla tillräckligt med information om felsituationen så att konsumenten har en chans att återhämta sig från avbrottet med så liten påverkan som möjligt på arbetsflödet. K 5 Tid hanteras internt och lagras i UTC, men ska kunna presenteras i lokal sommar- och vintertid. K 6 Tidssynkronisering av ingående tjänster skall ske K 7 Tjänsterna skall vara övervakningsbara avseende fysisk och logisk funktionalitet K 8 Tjänsterna skall kunna prestandamätas i drift 3.6 Generella icke-funktionella krav 3.6.1Prestanda Användbarheten för BIF står och faller med goda prestanda, eftersom svarstiderna från ITtjänsterna indirekt påverkar användarens upplevda svarstid i applikationerna. Viktiga egenskaper är därför korta svarstider från tjänsterna vid såväl registrering, läsning som notifiering. En viktig konstruktionsfaktor är möjligheten för IT-tjänster att på ett effektivt sätt utnyttja varandra utan att onödigt och tidskrävande resursutnyttjande skapas för IT-tjänsterna. I situationer där tjänster anropar varandra i kedjor, sk. kaskadering, introduceras onödiga anrop till BIF-tjänsterna om inte mekanismer för att undvika detta finns Programmerings- utvecklings och driftsmiljö Anges vid en upphandling. Minimum.NET och Java för agenter och fasad Övriga generella icke-funktionella krav Tjänsterna skall utformas att exponeras i öppna publika nätverk. Formuleras vid anskaffning. 3 Med det menas att tjänster fungera både i en centraliserad och i en distribuerad miljö. Designen av tjänsterna skall medge att en logisk tjänst kan vara fysiskt distribuerad (=flera instanser). Likaså skall flera organisationer kunna dela på en tjänst dvs en instans skall kunna vara logiskt uppdelad. Maj
26 3.7 Grundläggande beståndsdelar Basen för IT-tjänster är en Tjänstebaserad arkitektur (Service Oriented Architecture=SOA). Principen för SOA är att tydligt urskiljbara delar med bestämda uppgifter och standardiserade gränssnitt utbyter tjänster, services, med varandra genom meddelande, se figur 9. Figur 10 Principen för en SOA-tjänst I BIF är baskonceptet för SOA kompletterat med säkerhetsfunktionalitet Biljett En användare autentiseras endast en gång och detta skall ske minst på lägsta säkra och överenskomna nivå (i dagsläget SITHS). Autentiseringstjänsten skapar intyg som innehåller information om användarens identitet och egenskaper. Genom att signera dessa intyg går Autentiseringstjänsten i god för att det som intygas är korrekt Intygen samlas och paketeras i en biljett som överföres till användarens klientarbetsplats eller görs åtkomlig vid autentisering via webapplikation. Genom uppvisandet av biljetten får användaren sedan eventuell åtkomst till andra IT-tjänster. Eftersom Autentiseringstjänsten är betrodd av andra BIF-tjänster litar de på biljettinnehållet Fasad 4 En fasad är en gränssnittskomponent som varje IT-tjänst instansierar och den ger på ett smidigt och enkelt sätt IT-tjänsten tillgång till BIF-tjänsternas funktionalitet. Förutom att hantera signering och kryptering av meddelanden, tolkar och verifierar fasaden rättighetssbiljetter och ansvarar för loggning. Alla meddelanden som skickas till och från BIFsäkrade tjänster passerar alltid genom fasaden. Fasaden utnyttjar många av BIF-tjänsterna och för de BIF-tjänster som har agenter placeras dessa i fasaden. 4 Fasad skall uttydas Fasadkomponent, och ej förväxlas med designmönstret Façade. Maj
27 Figur 11 Fasad med agenter Genom utnyttjandet av en specificerad fasad, kan centrala och väsentliga säkerhetsrelaterade uppgifter 5 skötas på ett uniformt sätt för alla IT-tjänster. Genom att tillföra denna funktionalitet i en fasad, kan utvecklingen av IT-tjänster för vård och omsorgsverksamhet förenklas. Fasaden är av nödvändighet knuten till viss teknik genom att den skall implementeras för den runtime-miljö i vilken den länkas in. Därför skall fasader utvecklas för aktuella miljöer som i dagsläget är.net och Java. Fasaden ger enkelhet för utvecklare (läs billigare), enhetlig certifierad användning av BIFtjänsterna samt garanterar en säker kommunikation med IT-tjänster, inom och utom organisationer. 5 Säkerhetsrelaterade uppgifter är signering, kryptering, biljetthantering, autentisering, auktorisering och loggning. Maj
28 Figur 12 SOA-tjänst kompletterat med säkerhetsfunktionalitet (signering, kryptering) För att säkerställa att ett meddelande inte förvanskats och för att erhålla oavvislighet signeras meddelanden med XML-Signature enligt WS-Security. Mottagaren av meddelandet skall alltid kontrollera och verifiera signaturen. Tanken är att fasaden med automatik utför dessa operationer. Om meddelandet förses med insynsskydd genom kryptering används XML- Encryption enligt WS-Security. Fasaden innehåller även funktionalitet för kryptering och dekryptering Klientkomponent Hela säkerhetslösningen bygger på en biljetteknik där autentiseringstjänsten utfärdar betrodda intyg, vilka uttalar sig om användarens egenskaper. På klientsidan kan detta implementeras på två sätt, lokalt exekverande klient eller klient uppdelad på browserdel och server Lokalt exekverande klient Genom specifikation av en arbetsstationskomponent, kan e-id kort, certifikatshantering och biljetteknik skötas på ett uniformt sätt. På användares datorarbetsplats kan dessutom funktionalitet hos fasaden utnyttjas. Fasader hanterar signering och kryptering och all biljetthantering, men på arbetsstationen behövs även stöd för att initialt knyta den inloggande användaren till en biljett. Efter det att denna knytning är gjord, representeras användaren av denna biljett. En komponent, AuthenticationAgent, finns därför på arbetsstationen med uppgift att hantera den klientspecifika biljetthanteringen. Maj
29 Figur 13 Lokalt exekverande klient Browserbaserad klient I det browserbaserade fallet är den funktionalitet som i ovanstående beskrivning utförs av AuthenticationAgent flyttad till en IT-tjänst. IT-tjänsten kan exempelvis vara en portalserver. Funktionaliteten är densamma som när en IT-tjänst anropar en annan IT-tjänst. För att hantera inloggning i webmiljö används SAML 2.0 Web Browser SSO Profile. En webapplikation som önskar autentisera en aktör skickar aktören till autentiseringstjänstens webgränssnitt. Efter autentisering returneras användaren till webapplikationen tillsammans med information om hur biljett kan uthämtas Trust via biljett Säkerhetskonceptet i BIF innebär att varje IT-tjänst som mottar ett meddelande skall verifiera såväl meddelandets riktighet och ursprung som att den i meddelandet medföljande biljetten är äkta och tillförlitlig. Själva meddelandets riktighet och ursprung garanteras genom att IT-tjänsten kryptografiskt verifierar meddelandets signatur. Biljettens autenticitet måste också kontrolleras innan de ingående aktörsegenskaperna används för exekvering av rättighetsregler. Att biljetten medföljt det signerade meddelandet är inte tillräckligt. Det krävs att mottagande IT-tjänst med visshet kan verifiera att: biljetten är riktig och oförvanskad vilket görs genom att verifiera utfärdens signatur på biljetten aktören, vars egenskaper biljetten beskriver, också är den som signerat meddelandet vilket görs genom att kontrollera att signaturen på meddelandet är gjord av samma aktör som beskrivs i den medföljande biljetten. Maj
30 biljetten är utfärdad av en känd och betrodd (certifierad) autentiseringstjänst Om det bara fanns en autentiseringstjänst vore detta inget problem. Men precis som andra IT-tjänster kan en organisation ha flera autentiseringstjänster, kan en autentiseringstjänst delas av flera organisationer, kan nya autentiseringstjänster tillkomma eller så kan autentiseringstjänster läggas ner osv. Trots denna föränderliga miljö måste varje IT-tjänst vid varje tillfälle kunna verifiera att en mottagen biljett utfärdats av en betrodd (certifierad) autentiseringstjänst. Detta skall ske genom en särskild certifieringsprocess där varje autenticeringstjänst godkänns och tilldelas unika egenskaper (attribut) i sina tjänstecertifikat (dvs SITHS funktions-hcc). Därvid kan IT-tjänster genom att kontrollera biljettutfärdarens certifikat avgöra om denna är den autentiseringstjänst den utger sig för att vara. Nödvändig funktionalitet för verifiering av meddelande och biljetter kommer att finnas i Fasaden vilket innebär att utvecklare av IT-tjänster inte behöver belastas med detta Samverkan De tre huvudbeståndsdelarna biljett, fasad och lokalt exekverande klientkomponent samverkar, så att en säkerhetsmässig enhet nås, se figur 15. Figur 14 Biljett-fasad-kliensamverkant När istället en webbläsare används, blir förloppet enligt figur 15. Maj
31 Figur 15 Samverkan i webklient 3.8 Generella behov I en tjänsteorienterad arkitektur, där IT-tjänsterna är självständiga och endast löst kopplade med anrop och svar, krävs att IT-tjänsternas funktion styrs och regleras på en högre nivå, så att bl.a. koordinering, upptäckt mm fungerar. Praktiskt kan behoven för bl.a. BIF-tjänsterna uttryckas som behov av ett Tjänstelager. Detta tjänstelager består bl.a. av själva IT-tjänsterna (BIF och vårdtjänster mm), tjänsteregister och eventuell tjänsteförmedlare. I varje organisation måste finnas en logik för att hålla reda på vilka IT-tjänster som finns ett tjänsteregister. Arbete inom RIV pågår för att uppgradera det tjänsteregister som finns beskrivet i RIV-HSA. Vidare kan anrop mellan IT-tjänster behöva förmedlas via en tjänsteförmedlare. För varje ny organisation som IT-tjänsterna ska verka i, finns behovet av att hitta relevanta IT-tjänster dvs ett tjänsteregister behövs även mellan organisationer, men kan organiseras på olika sätt (regionalt, nationellt), se figur. Ett flertal kommersiella produkter finns tillgängliga för SOA-funktioner som orkestrering, koreografering, tjänsteregister och tjänsteförmedlare, men även fria standarder som WS- BPEL 2.0, UDDI och WS-Choreografy finns. De generella behoven för IT-tjänster behandlas inte i denna rapport, men måste bearbetas och beslutas om på liknande sätt som BIF-tjänster. Detta kan i sin tur påverka vissa lösningar i BIF-tjänsterna. Maj
32 Figur 16 Schematisk bild av tjänsteregister och tjänstemäklare. Maj
33 4 IT-tjänst för autentisering 4.1 Tjänstespecifikation: Autentisering Syfte med tjänsten Autentiseringstjänsten har i uppgift att vid inloggning fastställa aktörens identitet samt sammanställa och intyga dennes egenskaper i en e-underskriven biljett, som sedan kan användas som underlag för rättighetsstyrning i övriga IT-tjänster. En aktör kan vara en fysisk person eller IT-tjänst som behöver åtkomst till andra IT-tjänster. 4.3 Konceptuell beskrivning av tjänsten Autentiseringstjänsten skall Verifiera aktörens identitet genom autentisering Knyta egenskaper till aktören Intyga den styrkta identiteten och tillhörande egenskaper till de IT-tjänster som efterfrågar detta BIF hanterar olika kategorier av aktörer. En aktör kan i detta sammanhang vara: En fysisk person En IT-tjänst En aktör skall vara upplagd i en HSA-katalog och vara identifierad genom SITHS-certifikat. För allmänheten gäller medborgarcertifikat. I en IT-tjänst för administration av egenskaper e-undertecknas dessa av en administratör. Varje medarbetare är unikt identifierad med ett HSA-id, som är en global unik identitet konstruerad utifrån Hälso- och Sjukvårdens Adressregister (HSA). Personer i hälso- och sjukvården identifierar sig med ett certifikat som bygger på SITHS. Invånare autentiserar sig med en godkänd e-legitimation. Invånare behöver då inte vara registrerad eller känd sedan tidigare, men IT-tjänsten för autentisering kan verifiera certifikatets giltighet, att certifikatet är utfärdat av betrodd instans och därmed styrka användarens identitet. Vid autentiseringen knyts egenskaper till användaren och dennes identitet. IT-tjänst för autentisering försäkrar att en aktör har identifierats, autentiserats och är förknippad med vissa egenskaper. Denna försäkran skall kunna användas för åtkomst till applikationen istället för att begära ny autentisering av användaren. En sådan försäkran utgörs av en signerad biljett innehållande information om aktuell användare och dess egenskaper. I BIF används SAML standarden som biljettformat. 4.4 Avgränsning Autentiseringstjänsten placerar inga åtkomstbeslut eller regler i biljetten. 4.5 Funktionella krav KA 1. Autentiseringstjänsten skall via definierad autentiseringsmetod avkräva en godkänd autentisering av användaren innan ett intyg (SAML biljett) skapas. KA 2. En användare skall kunna vara en person eller IT-tjänst Maj
34 KA 3. PKI-baserad inloggning med X.509 v3 certifikat av typen e-id (medborgarcertifikat) och Health Care Certificates (HCC) enligt SITHS-modellen skall användas. KA 4. Det skall finnas funktioner för att konfigurera vilket/vilka attribut i X.509 certifikatet som används för att identifiera användaren (t.ex. Subject Name, Serial Number, Common Name osv). I denna version gäller att medborgare som autentiserar sig med e-id identifieras med personnummer Serial Number i certifikatet medan hälso- och sjukvårdspersonal som autentiserar sig med HCC identifieras med HSA-id också Serial Number i certifikatet. KA 5. Godkända certifikatutgivare skall kunna specifieras för respektive tillämpning av PKI som metod. KA 6. Vid användning av certifikat för autentisering skall systemet kunna utföra kontroll av certifikatets status (spärrinformation). KA 7. Tjänsten skall ställa ut ett logiskt intyg om användaren i form av SAML biljett. Biljetten skall kunna innehålla: - användarens identitet - dennes egenskaper - information om aktuell autentiseringsmetod - giltighetstid KA 8. Autentiseringstjänsten skall ta fram elektroniskt undertecknade användaregenskaper och förmedla dessa i biljetten. KA 9. Vid autentisering skall verifierade certifikat kunna förmedlas tillsammans med intyg utgivet från Autentiseringstjänsten. KA 10. Intyget skall säkert kunna knytas till den användare som presenterar biljetten för ITtjänsterna (proof of posession). Detta skall göras genom att meddelandet som skickas från användarens klient e-underskrivs. KA 11. Autentiseringstjänsten skall kunna användas i lösningar som bygger på feta och/eller tunna klienter. KA 12. Alla aktiviteter i Autentiseringstjänsten skall loggas av Loggtjänsten. KA 13. I loggen skall framgå tidpunkt, om godkänd/nekad, användarid (där tillämpligt), händelsetyp, målsystem/applikation (där tillämpligt) varifrån (ip-adress/nummer) begäran om autentisering kom, samt använd autentiseringsmetod. Vid nekande skall orsak framgå. KA 14. Nationellt överenskomna egenskaper skall kunna kompletteras med lokala egenskaper. Varje mängd av lokala egenskaper skall kvalificeras med ett unikt namespace. KA 15. Stöd skall finnas för att kunna påverka informationsuppsättningen i biljetten vid inloggning. Till exempel skall verksamhetsuppdrag samt syfte kunna vara valbart. KA 16. Autentiseringstjänsten skall ha stöd för att hantera autentisering för webapplikationer. I webfallet skall tjänsten själv presentera och låta aktören välja de faktorer som påverkar biljetten, om nödvändigt. Biljett skall föras tillbaka till webapplikationen med hjälp av SAML Web Browser SSO Profile med HTTP Redirect binding (för AuthnRequest) samt HTTP Artifact binding (för Response). 4.6 Tjänstegränssnitt: Funktioner Funktion Autentisera Hämta aspekter Anm. Utifrån uppvisat identifieringsbevis autentiseras användaren Hämta lista med valbara aspekter för användaren Maj
35 Funktion Begär attributintyg Anm. Hämta intyg med ytterliggare attribut för viss användare 4.6.1Autentisera (Authenticate) Beskrivning Genom att aktören levererar sin identitet och signerar med ett giltigt certifikat som med säkerhet kan knytas till aktören autentiseras denne. En SAML biljett skapas som innehåller autentiserings och attributintyg.. Biljettens innehåll kan vid autentiseringen styras med inparametrar, det som här kallas aspect. För att skapa attributintyget förlitar sig autentiseringstjänsten på undertecknade aktörsegenskaper som hämtas från andra källor t.ex. HSA-katalogen Inparametrar Typ Namn Beskrivning xml AspectChoices AspectChoices håller en lista med de valda värdena för varje aspekt. Denna kan ses som en lista med nyckel och värdepar. Nyckeln är aspektens Key och värdet är Value. Autentiseringstjänsten måste säkerställa att aspekternas valda värden är acceptabla för den användare som autentiseras. De valda aspektvärdena som används avgör, till exempel, vilken alternativ attributuppsättning som skall läggas i biljetten eller specifika värden för olika biljettattribut. Detta kan användas för att låta en användare med ett enda certifikat få ut biljetter med olika innehåll Resultat En biljett i form av ett SAML assertion returneras vid lyckad autentisering. Innehållet i biljetten beskrivs i avsnitt 13.4 SAML biljetten skall vara signerad av autentiseringstjänsten Ingångsvillkor För att styrka aktörens identitet skall meddelandet vara signerat med aktörens certifikat ur vilket också aktörens id hämtas Utgångsvillkor Om aktören kunde autentiseras skapas en SAML biljett, populerad med attribut från den säkra attributkällan som autentiseringstjänsten använder sig av. De valda aspektvärdena skall lagras för användaren och returneras som respektive aspekts CurrentValue när GetAspects anropas Felhantering Fel levereras som beskriver varför användaren inte kunde autentiseras. Felen ska loggas. Följande fel (faults) skall användas: UnknownUserFault Certifikatet är giltigt men användarens identitet kan inte fastställas. Maj
Certifikat - Ett av en CA elektroniskt signerat intyg som knyter en publik nyckel till en specifik nyckelinnehavare. Källa: Inera (BIF)
A Autentisering - Kontroll av uppgiven identitet. Källa: SOSFS 2008:14 Autentisering - Kontroll av uppgiven identitet, t ex vid inloggning, vid kommunikation mellan system eller vid utväxling av meddelanden
Läs merTillämpningsanvisningar för tillgång till och utlämnande av patientinformation
Sid 1(5) Tillämpningsanvisningar för tillgång till och utlämnande av patientinformation Inledning Hantering av patientinformation inom Region Skåne ska ske utifrån patientdatalagen (SFS 2008:355), Socialstyrelsens
Läs merInnehåll. Nationell IT-strategi och målbild Nationell infrastruktur Nationell Patient Översikt - NPÖ
Innehåll Nationell IT-strategi och målbild Nationell infrastruktur Nationell Patient Översikt - NPÖ Information som ska användas i NPÖ Produktval NPÖ Tidplaner och aktiviteter för NPÖ Jan Edquist IT-arkitekt
Läs merApotekens Service. federationsmodell
Apotekens Service Federationsmodell Detta dokument beskriver hur Apotekens Service samverkar inom identitetsfederationer Datum: 2011-12-12 Version: Författare: Stefan Larsson Senast ändrad: Dokumentnamn:
Läs merRegelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga A. Tekniska ramverk. Version: 1.0
Regelverk Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag Bilaga A Tekniska ramverk Version: 1.0 Innehållsförteckning 1 Bakgrund och syfte... 1 1.1 Definitioner 1 2 Inledning...
Läs merRegelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga A. Tekniska ramverk. Version: 3.0
Regelverk Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag Bilaga A Tekniska ramverk Version: 3.0 Innehållsförteckning 1 Bakgrund och syfte... 1 1.1 Definitioner 1 2 Inledning...
Läs merXML-produkter. -Registret över verkliga huvudmän (RVH) Teknisk handledning för webbtjänst mot RVH (Web Services) Datum: Version: 1.
XML-produkter -Registret över verkliga huvudmän (RVH) Teknisk handledning för webbtjänst mot RVH (Web Services) Datum: 2018-09-18 Version: 1.0 Innehållsförteckning 1. Inledning... 3 1.1. Syfte 3 1.2. Målgrupp
Läs merWebbseminarium BIF-Utbildning för utvecklare Version 1.0.0
Typ av dokument Webbseminarium Datum 2009-07-02 Sida 1(85) Webbseminarium BIF-Utbildning för utvecklare Version 1.0.0 Innehållsförteckning 1. Introduktion... 4 1.1. Inledning... 4 1.2. Implementering...
Läs merHur kan medborgaren få bättre vård?
Hur kan medborgaren få bättre vård? Säkert informationsutbyte med federationslösning för utökad vårdkvalitet över organisationsgränser Presentatörer Stefan Wittlock, Hultsfreds kommun Tommy Almström, Nordic
Läs merChecklista. För åtkomst till Svevac
Checklista För åtkomst till Svevac Innehållsförteckning 1 Inledning 2 2 Inloggning/autentisering i Svevac 2 3 Målet sammanhållen vaccinationsinformation 3 4 Säkerhetstjänsten 3 5 Detta är HSA 3 6 Detta
Läs merModul 3 Föreläsningsinnehåll
2015-02-03 2015 Jacob Lindehoff, Linnéuniversitetet 1 Modul 3 Föreläsningsinnehåll Vad är ett certifikat? Användningsområden Microsoft Certificate Services Installation Laboration Ingår i Klustringslabben
Läs merInstruktion för integration mot CAS
IT-enheten Instruktion för integration mot CAS Per Hörnblad Instruktion 2010-10-29 Sid 1 (7) Instruktion för integration mot CAS Projektnamn Instruktioner för Integration mot CAS Fastställt av Per Hörnblad
Läs merSystemadministration. Webcert Fråga/Svar
Systemadministration Webcert Fråga/Svar Innehåll 1 Inledning... 2 1.1 Bakgrund... 2 1.2 Syfte och målgrupp... 2 1.3 Definitioner och benämningar... 2 2 Systemadministration av Webcert... 2 2.1 Behörigheter
Läs merNationell Tjänsteplattform och säkerhetsarkitektur. Per Brantberg, område arkitektur/infrastruktur
Nationell Tjänsteplattform och säkerhetsarkitektur Per Brantberg, område arkitektur/infrastruktur Nationell e-hälsa är vårt uppdrag Uppgiften är att skapa en väl fungerande informationsförsörjning inom
Läs merFedererad åtkomst Information om åtkomst till Apotekens Services tjänster inom ramen för en identitetsfederation.
Federerad åtkomst Information om åtkomst till Apotekens Services tjänster inom ramen för en identitetsfederation. Datum: 2011-02-28 Version: Författare: Christina Danielsson Senast ändrad: Dokumentnamn:
Läs merStark autentisering i kvalitetsregister
Stark autentisering i kvalitetsregister Användning av e-tjänstekort (SITHS) Kontaktinformation till RC Syd: Krav på säker autentisering i kvalitetsregister Enligt Socialstyrelsens föreskrifter SOSFS 2008:14
Läs merStark autentisering i kvalitetsregister
Stark autentisering i kvalitetsregister Användning av e-tjänstekort (SITHS) Kontaktinformation till RC Syd: rcsydkarlskrona@ltblekinge.se INNEHÅLLSFÖRTECKNING Bakgrund om SITHS 3 Instruktion till kvalitetsregister
Läs merPDL medarbetaruppdrag vårdgivare vårdenhet Organisation verksamhetschef. NetID drivrutiner kortläsare operativ browser
NetID drivrutiner kortläsare operativ browser webinar Checklista dokument wiki avreglering Apotek e-dos PDL medarbetaruppdrag vårdgivare vårdenhet Organisation verksamhetschef HSA SITHS attribut autentisering
Läs merEyeNet Sweden stark autentisering i kvalitetsregister
EyeNet Sweden stark autentisering i kvalitetsregister Användning av e-tjänstekort (SITHS) EyeNet Sweden Kontaktinformation till RC: eyenetsweden@ltblekinge.se INNEHÅLLSFÖRTECKNING Bakgrund om SITHS 3 Instruktion
Läs merTermer och begrepp. Identifieringstjänst SITHS
Termer och begrepp Identifieringstjänst Revisionshistorik Version Datum Författare Kommentar 1.0 2019-02.20 Policy Authority Fastställt 1.1 Policy Authority Mindre justeringar 1. Dokumentets syfte Definition
Läs merLeanlink Ao LKDATA. Teknik spåret. Föreläsare: Michael Lööw, Linköpings Kommun Michael.Loow@linkoping.se
Samverka effektivare via regiongemensam katalog Teknik spåret Föreläsare: Michael Lööw, Linköpings Kommun Michael.Loow@linkoping.se 1 Ännu inget genombrott för e-legitimation Moment 22 Inte intressant
Läs merNationell patientöversikt en lösning som ökar patientsäkerheten
NPÖ-guiden NPÖ Nationell Patientöversikt Nationell patientöversikt en lösning som ökar patientsäkerheten Den här guiden riktar sig till vårdgivare landsting, kommuner och privata vårdgivare som ska eller
Läs merTjänsteID+ Teknisk översiktsdokument etjänstekort, Privata vårdgivare
1.2 110908 (1)18 TjänsteID+, Privata vårdgivare 1.2 110908 (2)18 1.2 110908 (3)18 Innehåll Dokumentstruktur... 4 Bakgrund... 5 Organisation... 5 Extern information... 6 Certifikaten... 6 E-legitimation...
Läs merStark autentisering i kvalitetsregister Användning av e-tjänstekort (SITHS) Version 1.2
Stark autentisering i kvalitetsregister Användning av e-tjänstekort (SITHS) Version 1.2 Krav på säker autentisering i kvalitetsregister Enligt Socialstyrelsens föreskrifter SOSFS 2008:14 2 kap. 5 skall
Läs merDatum: 2011-02-10 Version: Författare: Christina Danielsson Senast ändrad:
I N T E R N T Säkerhetskrav på extern part För enskild individs direktåtkomst till Datum: 2011-02-10 Version: Författare: Christina Danielsson Senast ändrad: Dokumentnamn: Säkerhetskrav på extern part
Läs merStark autentisering i kvalitetsregister Inloggningsinformation för användning av e-tjänstekort (SITHS)
Stark autentisering i kvalitetsregister Inloggningsinformation för användning av e-tjänstekort (SITHS) Version 1.4 Krav på säker autentisering i kvalitetsregister Enligt Socialstyrelsens föreskrifter SOSFS
Läs merTjänster med åtkomst till personer med skyddade personuppgifter från HSA. Version 1.2.2,
er med åtkomst till personer med skyddade, Innehåll Introduktion... 2 er med åtkomst till personer med skyddade... 4 Revisionshistorik Version, datum Författare Kommentar 1.0, 2015-06-09 Ulrika Nilsson
Läs merStark autentisering i kvalitetsregister Användning av e-tjänstekort (SITHS) Version 1.3
Stark autentisering i kvalitetsregister Användning av e-tjänstekort (SITHS) Version 1.3 Krav på säker autentisering i kvalitetsregister Enligt Socialstyrelsens föreskrifter SOSFS 2008:14 2 kap. 5 skall
Läs merAvtal om Kundens mottagande av intyg från Mina intyg Bilaga 1 - Specifikation av tjänsten mottagande av intyg från Mina Intyg
Avtal om Kundens mottagande av intyg från Mina intyg Bilaga 1 - Specifikation av tjänsten mottagande av intyg från Mina Intyg Mellan Inera och Kund Innehåll 1. Inledning... 3 2. Bakgrund... 3 3. Syfte...
Läs merKoncernkontoret Området för informationsförsörjning och regionarkiv
Koncernkontoret Området för informationsförsörjning och regionarkiv Enheten för informationsstyrning och förvaltning Anvisning Datum 2017-03-01 Version 1.0 1 (5) Hantering av elektroniska underskrifter
Läs merRIV TA Basic Profile 2.1 med intygspropagering RIV Tekniska Anvisningar
RIV 2.1 Anvisningar Bilaga 5.1 CeHis Arkitekturledning Sida: 1 (7) RIV TA Basic Profile 2.1 2011-11-19 RIV 2.1 Anvisningar Bilaga 5.1 CeHis Arkitekturledning Sida: 2 (7) Utgåvehistorik Utgåva PA1 Revision
Läs merTermer och begrepp. Identifieringstjänst SITHS
Termer och begrepp Identifieringstjänst Revisionshistorik Version Datum Författare Kommentar 1.0 2019-02-20 Policy Authority Fastställd 1. Dokumentets syfte Definition av termer och begrepp som används
Läs merGränssnitt och identiteter. - strategiska frågor inom Ladok3
- strategiska frågor inom Ladok3 Sida 2 av 9 er Revision Datum Av Kommentar Granskare Godkännare 0.1 2011-05-26 Daniel Lind Utkast 0.2 2011-05-30 Daniel Lind Synpunkter från Catherine 0.3 2011-06-16 Daniel
Läs merAvtal om Kundens användning av Svevac Bilaga 1 - Specifikation av tjänsten Svevac
Avtal om Kundens användning av Svevac Bilaga 1 - Specifikation av tjänsten Svevac Innehåll 1. Inledning... 3 2. Bakgrund... 3 2.1 Referenser... 3 2.2 Definitioner... 4 3. Tjänstebeskrivning... 6 3.1 Syftet
Läs merTeknisk guide för brevlådeoperatörer. Annika Melin 2015-03-10 Version: 1.1
Teknisk guide för brevlådeoperatörer Annika Melin 2015-03-10 Sida 1 av 21 Innehållsförteckning Inledning... 2 1 Dokumentinformation... 3 Syfte... 3 1.2 Avgränsningar... 3 1.3 Målgrupp... 3 1.4 Begrepp
Läs merMobilt Efos och ny metod för stark autentisering
Mobilt Efos och ny metod för stark autentisering I och med lanseringen av E-identitet för offentlig sektor, Efos, kommer Inera att leverera komponenter som möjliggör att en användare ska kunna logga in
Läs merSamverka effektivare via regiongemensam katalog
Samverka effektivare via regiongemensam katalog Seminarium 4:6 Föreläsare: Michael Lööw, Linköpings Kommun Michael.Loow@linkoping.se Johan Zenk, Landstinget i Östergötland Ännu inget genombrott för e-legitimation
Läs merPhenixID & Inera referensarkitektur. Product Manager
PhenixID & Inera referensarkitektur Product Manager tommy.almstrom@phenixid.se PhenixID & Inera referensarkitektur PhenixID & Inera Identitetslager PhenixID & Inera Identifieringstjänst PhenixID & Inera
Läs merSäker e-kommunikation 2009-04-22
Säker e-kommunikation 2009-04-22 Leif Forsman Logica 2008. All rights reserved Agenda - Inledning - Bakgrund och historik - Vilka risker och hot finns? - Vilka säkerhetslösningar finns det för att skydda
Läs merViktigt förtydligande angående användningen av fråga-svarsfunktionen
2013-03-28 Vård och omsorg Cecilia Unge Viktigt förtydligande angående användningen av fråga-svarsfunktionen Det framgår att hälso- och sjukvården ibland skickar NY medicinsk information via frågasvarsfunktionen
Läs merBilaga 2. Säkerhetslösning för Mina intyg
Bilaga 2. Säkerhetslösning för Mina intyg Sid 1/17 Innehåll 1. Sammanfattning... 2 2. Inledning... 3 3. Introduktion... 4 4. Säkerhetslösning för Mina intyg... 5 5. Krav på andra lösningar och aktörer...
Läs merKrav på säker autentisering över öppna nät
Krav på säker autentisering över öppna nät I enlighet med Socialstyrelsens föreskrifter SOSFS 2008:14 2 kap. 5 skall en vårdgivare som använder öppna nät för att hantera patientuppgifter, ansvara för att
Läs merAnvisningar för användare vid användning av e- Tjänster. Anvisningar och rekommendationer för användare av e-tjänster i samverkan SAML & SSO
Anvisningar för användare vid användning av e- Tjänster Anvisningar och rekommendationer för användare av e-tjänster i samverkan SAML & SSO Innehåll Målgrupp... 2 Revisionshistorik... 2 Sammanfattning...
Läs merTjänsteavtal för ehälsotjänst
Tjänsteavtal för ehälsotjänst Bilaga 1. Specifikation av Tjänsten INNEHÅLLSFÖRTECKNING 1. Inledning... 3 2. Bakgrund... 3 2.1. Referenser... 4 3. Tjänstebeskrivning... 4 3.1. Syftet med Tjänsten... 4 3.2.
Läs merAutentisering till verksamhetssystem inom vård & omsorg
Sida 1 (5) 2009-11-11 Autentisering till verksamhetssystem inom vård & omsorg Beställare Beställare av detta underlag är Karin Bengtsson, KSL/IT-Forum. Syfte Syftet med detta dokument är att redovisa den
Läs merSammanfattning och specifikationer för POT
0.2 Sammanfattning och specifikationer för POT Kornhamnstorg 61 SE-111 27 Stockholm Sweden 00 00 Telefon: +46 (0)8 791 92 Telefax: +46 (0)8 791 95 www.certezza.net Innehållsförteckning 1 SAMMANFATTNING...
Läs merDirektkoppling till Girolink Internet. Filöverföring av betalningar och betalningsinformation via Girolink Internet. Version 1.0
Direktkoppling till Girolink Internet Filöverföring av betalningar och betalningsinformation via Girolink Internet Version 1.0 Maj 2007 Innehållsförteckning 0. DOKUMENTHISTORIK 1 ALLMÄNT - DIREKTKOPPLING
Läs merBehörighetssystem. Ska kontrollera att ingen läser, skriver, ändrar och/eller på annat sätt använder data utan rätt att göra det
Behörighetssystem Ska kontrollera att ingen läser, skriver, ändrar och/eller på annat sätt använder data utan rätt att göra det Systemet måste kunna registrera vilka resurser, d v s data och databärande
Läs merPolicy Underskriftstjänst Svensk e-legitimation
Policy Underskriftstjänst Svensk e-legitimation Version 1.0 2014-04-15 1 (7) 1 INLEDNING OCH SYFTE 3 1.1 AVGRÄNSNINGAR 3 1.2 DEFINITIONER 3 2 POLICYPARAMETRAR 4 2.1 DATALAGRING 4 2.1.1 LAGRING AV INFORMATION
Läs merFörklaringar till Nationellt regelverk för enskilds direktåtkomst till journalinformation
Förklaringar till Nationellt regelverk för enskilds direktåtkomst till Bakgrund Regelverket är utarbetat utifrån erfarenheter i Landstinget i Uppsala län, där nästan 50 000 användare haft tillgång till
Läs merPolicy och tillämpningsförslag. Informationsutbyte. mellan externa vårdgivare och Region Skåne
Hälso- och sjukvårdsledningen POLICY Datum December 2004 Dnr HSN/000000 Policy och tillämpningsförslag Informationsutbyte mellan externa vårdgivare och Region Skåne Adress: S-291 89 KRISTIANSTAD Besöksadress:
Läs merRiktlinje för informationshantering och journalföring
RIKTLINJER HÄLSO- OCH SJUKVÅRD Sid 1 (5) Riktlinje för informationshantering och journalföring Nedanstående lagar, förordningar föreskrifter och allmänna råd ligger till grund för omvårdnadsdokumentationen.
Läs merVarför Sambi, för vad och vem, samexistens med andra lösningar, svensk e-leg, SITHS, HSA, Skolfederation et cetera (Ulf Palmgren, SKL, CeSam)
Varför Sambi, för vad och vem, samexistens med andra lösningar, svensk e-leg, SITHS, HSA, Skolfederation et cetera (Ulf Palmgren, SKL, CeSam) Vad finns idag? Landstingen har SITHS, HSA, Säkerhetstjänster,
Läs merFilleveranser till VINN och KRITA
Datum Sida 2017-04-25 1 (10) Mottagare: Uppgiftslämnare till VINN och KRITA Filleveranser till VINN och KRITA Sammanfattning I detta dokument beskrivs översiktligt Vinn/Kritas lösning för filleveranser
Läs merRutin vid kryptering av e post i Outlook
Beslutad av: Chef Säkerhet och beredskap Diarienummer: RS 255 2016 Giltighet: från 2016 03 31 [rev 18 11 01] Rutin vid kryptering av e post i Outlook Rutinen gäller för alla förvaltningar och bolag Innehållsansvar:
Läs merRiktlinjer för informationshantering och journalföring i hälsooch sjukvården i särskilt boende i Järfälla kommun.
2008-08-15 1 (6) Reviderad 2010-04-21 Riktlinjer för informationshantering och journalföring i hälsooch sjukvården i särskilt boende i Järfälla kommun. Nedanstående lagar, förordningar allmänna råd ligger
Läs merTestning av Sambi. Testplan. Version PA12. Fil namn: SAMBI_TP.docx Senast sparad: 2014-11- 24. Copyright (c) 2014 IIS
Testning av Sambi Testplan Version PA12 Fil namn: SAMBI_TP.docx Senast sparad: 2014-11- 24 Copyright (c) 2014 IIS Dokument kontroll Dokument information och säkerhet Skapad av Faktaansvarig Dokumentansvarig
Läs merHSA Kunskapstest för HSA-ansvariga
HSA Kunskapstest för HSA-ansvariga HSA Kunskapstest består av två delar. Del ett innehåller 10 frågor där bara ett svarsalternativ per fråga är rätt. Del två innehåller 27 frågor där flera svarsalternativ
Läs merManual - Inloggning. Webbadress: https://svevac.inera.se Webbadress demoversion: https://test.svevac.inera.se (användarnamn: demo / lösenord: demo)
Manual - Inloggning Svevac Webbadress: https://svevac.inera.se Webbadress demoversion: https://test.svevac.inera.se (användarnamn: demo / lösenord: demo) Supportärenden Kontakta i första hand din lokala
Läs merSekretess, lagar och datormiljö
Sekretess, lagar och datormiljö VT 2015 Sekretess och tystnadsplikt Tystnadsplikt gäller oss som individer Tystnadsplikt är ett personligt ansvar vi alltid har, vare sig vi agerar i tjänsten eller som
Läs merRegelverk för digital utomlänsfakturering
TJÄNSTESKRIVELSE Sida 1 (2) Landstingsdirektörens stab Kanslienheten Datum 2018-03-20 Diarienummer 180184 Landstingsstyrelsen Regelverk för digital utomlänsfakturering Förslag till beslut Landstingsstyrelsen
Läs merSITHS på egna och andra organisationers kort. Hur SITHS kort-information uppdateras i HSA
SITHS på egna och andra organisationers kort Hur SITHS kort-information uppdateras i HSA Innehållsförteckning 1. Certifikat och kortadministration HSA och SITHS... 2 1.1 SITHS en förtroendemodell... 2
Läs merEn övergripande bild av SITHS
En övergripande bild av SITHS Kontakt: Jessica Nord E-post: servicedesk@inera.se Webbsida: www.siths.se 1 2 Nationell e-hälsa SITHS en pusselbit Vad används SITHS till? Fysisk ID-handling Inpassering Säker
Läs merBilaga 3c Informationssäkerhet
SID 1 (5) Bilaga 3c Informationssäkerhet Förfrågningsunderlag Upphandling av IT-stöd för barn- och elevregister inom Skolplattform Stockholm Box 22049, 104 22 Stockholm. Besöksadress Hantverkargatan 2
Läs merAnsvarsförbindelse för Stockholms Läns Landstings Elektroniska Katalog (EK)
Ansvarsförbindelse för Stockholms Läns Landstings Elektroniska Katalog (EK) [Organisation som Ansvarsförbindelsen gäller] Modell Anvisning Dokumentation Blankett Rapport Namn Datum Version Ansvarig utgivare
Läs merMobilt Efos och ny metod för stark autentisering
Mobilt Efos och ny metod för stark autentisering I och med lanseringen av E-identitet för offentlig sektor, Efos, kommer Inera att leverera komponenter som möjliggör att en användare ska kunna logga in
Läs merHur får jag använda patientjournalen?
Hur får jag använda patientjournalen? Offentlighets- och sekretesslagen Patientdatalagen Vision 2014-01-30 Susan Ols Landstingsjurist Översikt När får jag läsa i patienters journaler? Sekretess - När jag
Läs merHandbok för användare. HCC Administration
Handbok för användare HCC Administration HCC Administration Handbok 2 Version 2.10.3 Informationen gäller från 2010-12-07, med reservation för eventuella ändringar. Din administratör kan förse dig med
Läs merFöretagens användning av ID-tjänster och e-tjänster juridiska frågor
Företagens användning av ID-tjänster och e-tjänster juridiska frågor Per.Furberg@Setterwalls.se Per Furberg advokat Sekreterare/expert i olika utredningar 1988 1998 http://www.setterwalls.se F.d. rådman
Läs merRiktlinje för hälso- och sjukvårdsdokumentation
Riktlinje för hälso- och sjukvårdsdokumentation Journalhandling En journalhandling är alla handlingar och anteckningar som innehåller uppgifter om patientens tillstånd och de åtgärder som genomförts eller
Läs merNationell Patientöversikt NPÖ. Anders Namn, arbetsplats, Jacobsson, datum IT-arkitekt, IT-centrum, 2012-02-02
NPÖ NPÖ ur ett användningsperspektiv Sammanhållen journalföring enligt Patientdatalagen Informationsåtkomst över vårdgivargränser Patientens samtycke krävs vid åtkomst Nationell, regional och lokal patientöversikt
Läs merMobilt Efos och ny metod för stark autentisering
Mobilt Efos och ny metod för stark autentisering I och med lanseringen av E-identitet för offentlig sektor, Efos, kommer Inera att leverera komponenter som möjliggör att en användare ska kunna logga in
Läs merUtfärdande av SITHS-kort. Utbyte av kort som inte klarar av SITHS CA v1 certifikat
Utfärdande av SITHS-kort Utbyte av kort som inte klarar av SITHS CA v1 certifikat Innehåll 1. Bakgrund... 2 2. Identifiera kort att byta ut... 2 3. Utfärda SITHS-kort... 3 3.1 Förutsättningar... 3 3.2
Läs merMVK SSO 2.0 Mina vårdkontakter
Ämne Version Datum Introduktion MVK SSO 2.0 1.7 2014-02-14 Ansvarig Dokument ID Sign Martin Carlman/Peter Bäck MVK-0031 Version Datum Av Avsnitt Ändring 1.7 140214 AL MVK SSO 2.0 Mina vårdkontakter MVK
Läs merAtt använda kryptering. Nyckelhantering och protokoll som bygger på kryptering
Att använda kryptering Nyckelhantering och protokoll som bygger på kryptering 1 Nyckelhantering Nycklar måste genereras på säkert sätt Nycklar måste distribueras på säkert sätt Ägaren av en nyckel måste
Läs merManual - Inloggning. Svevac
Manual - Inloggning Svevac Webbadress: https://svevac.inera.se Webbadress demoversion: https://test.svevac.inera.se (användarnamn: demo / lösenord: demo) Supportärenden: Kontakta i första hand din lokala
Läs merRutin för loggning av HSL-journaler samt NPÖ
Rutin för loggning av HSL-journaler samt NPÖ Enligt patientdatalagen 4 kap 3,skall vårdgivare göra systematiska och återkommande kontroller av om någon obehörigen kommer åt sådana uppgifter om patienter
Läs merTeknisk infrastruktur för nationell IT-strategi för vård och omsorg samt kommunal e-förvaltning
Teknisk infrastruktur för nationell IT-strategi för vård och omsorg samt kommunal e-förvaltning Presentation målbild, syfte och omfattning Sara Meunier Kurt Helenelund Version PA2 Svenska Kommunförbundet
Läs merTillsyn enligt personuppgiftslagen (1998:204) Behandling av känsliga personuppgifter i mobila enheter
Datum Diarienr 2013-05-08 1552-2012 Socialnämnden i Norrköpings kommun Rådhuset 601 81 Norrköping Tillsyn enligt personuppgiftslagen (1998:204) Behandling av känsliga personuppgifter i mobila enheter Datainspektionens
Läs merPraktikfall i vården 2012-10-03
Praktikfall i vården 2012-10-03 Praktikertjänst AB Praktikertjänst är ett aktiebolag men har en producentkooperativ ram där de 2120 aktieägarna själva arbetar på mottagningar runt om i landet Affärsområde
Läs merInformationssäkerhet i patientjournalen
RIKTLINJER FÖR Informationssäkerhet i patientjournalen Antaget av Vård- och omsorgsnämnden Antaget 2019-04-02 Giltighetstid 2023-04-02 Dokumentansvarig Medicinskt ansvarig sjuksköterska Håbo kommuns styrdokumentshierarki
Läs merInformationshantering och journalföring. nya krav på informationssäkerhet i vården
Informationshantering och journalföring nya krav på informationssäkerhet i vården Sammanhållen journalföring! Förklaring av symbolerna Patient Verksamhetschef Hälso- och sjukvårdspersonal samt övriga befattningshavare
Läs merInformationssäkerhet med logghantering och åtkomstkontroll av hälso- och sjukvårdsjournaler i Vodok och nationell patientöversikt (NPÖ)
Riktlinjer för hälso- och sjukvård inom Stockholms stads särskilda boenden, dagverksamhet och daglig verksamhet Sida 0 (8) Vers. 2.0 Rev. 2018 Informationssäkerhet med logghantering och åtkomstkontroll
Läs merFederering i praktiken
Federering i praktiken IT-forum Stockholms län 26 kommuner + Gotland och Stockholms läns landsting 2,1 miljoner invånare Byggstenar för samverkan Informationsklassning Autentisering Katalogsamverkan Identitetsfederering
Läs merSammanhållen journalföring och Nationell Patientöversikt i Västra Götalandsregionen
Sammanhållen journalföring och Nationell Patientöversikt i Västra Götalandsregionen Definition av begrepp Vårdgivare, regionen är vårdgivare enligt lagens definition, med ansvar att bestämma övergripande
Läs merLäkarsekreterarforum 2012
Patientdatalagen, journaler på nätet, sociala medier lagar och regler Läkarsekreterarforum 2012 Jens Larsson, 0706-110179 Jens Larsson, Chefsjurist Tryckfrihetsförordningen 1766 Jens Larsson, Chefsjurist
Läs merRIKTLINJE NATIONELLA PATIENT ÖVERSIKTEN (NPÖ)
STYRDOKUMENT RIKTLINJE NATIONELLA PATIENT ÖVERSIKTEN (NPÖ) 2017-2018 Dokumenttyp Dokumentnamn Fastställd/upprättad Beslutsinstans Giltighetstid Riktlinje Riktlinje Nationella Patient 2017-01-23 KS 17 KS
Läs merVIFO-kartan Verksamhetens Informations- och Funktionalitets-Områden för vård och omsorg med fokus på hälso- och sjukvård
VIFO-kartan Verksamhetens Informations- och Funktionalitets-Områden för vård och omsorg med fokus på hälso- och sjukvård Dokumentation för överlämning till Socialstyrelsen 2012-12-31 2 Syfte med VIFO-kartan
Läs merFormulärflöden (utkast)
2017-03-15 1 (17) PROJEKT SERVERAT Formulärflöden (utkast) ARKITEKTUR, BILAGA 1, VER 0.7, 2017-03-16 Sveriges Kommuner och Landsting, Tfn: växel 08-452 70 00, Fax: 08-452 70 50 Org nr: 222000-0315, info@skl.se,
Läs merPosthantering och annan överföring av sekretessbelagd och integritetskänslig information
Koncernkontoret Enheten för informationssäkerhet informationssakerhet@skane.se Datum: 2012-11-05 Dnr: Dokumentförvaltare: Enheten för informationssäkerhet Koncernkontoret Dokumentets status: Beslutat Dokumentid:
Läs merAvtal om Kundens användning av
Avtal om Kundens användning av Informationsutlämning till NKRR Bilaga 1 Specifikation av tjänsten Informationsutlämning till NKRR Mellan Inera och Kund Innehåll 1. Inledning... 3 2. Bakgrund... 3 2.1 Referenser...
Läs merHur skyddas patientens integritet? Vad säger lagar och författningar och hur fungerar det?
Hur skyddas patientens integritet? Vad säger lagar och författningar och hur fungerar det? ewa.jerilgard@cehis.se Dagens nyheter vintern 2012 Drygt 200 vårdenheter allt från sjukhus till vårdcentraler
Läs merRiktlinjer för dokumentation och informationshantering inom hälsooch sjukvårdens område i Nyköpings kommun
Riktlinjer utarbetade för: Vård och Omsorgsnämnden Kvalitetsområde: Hälso- och sjukvård Framtagen av ansvarig tjänsteman: Annika Jansson, Anna- Karin Tholerus Medicinskt ansvariga sjuksköterskor Giltig
Läs merNationell Patient Översikt i Sverige Swedish ehealth approach
Nationell Patient Översikt i Sverige Swedish ehealth approach Ulrika Landström, RN, Projektledare Örebro Läns Landsting ulrika.landstrom@orebroll.se +46 70 316 4541 Bakgrund och syfte Projektet startade
Läs merKändisspotting i sjukvården
Kändisspotting i sjukvården Sten Jacobson Grundprincip för hälso- och sjukvården Hälso- och sjukvården ska bygga på respekt för patientens integritet och självbestämmande. PDL ska ge en bättre samverkan
Läs merTekniskt ramverk för Svensk e- legitimation
Tekniskt ramverk för Svensk e- legitimation ELN-0600-v1.4 Version: 1.4 2015-08-14 1 (10) 1 INTRODUKTION 3 1.1 IDENTITETSFEDERATIONER FÖR SVENSK E- LEGITIMATION 3 1.2 TILLITSRAMVERK OCH SÄKERHETSNIVÅER
Läs merSentrion och GDPR Information och rekommendationer
Information och rekommendationer Innehållsförteckning GDPR... 3 Principer... 3 Registrerades rättigheter... 3 Sentrion och GDPR... 4 Laglighet, korrekthet och öppenhet... 4 Ändamålsbegränsning... 4 Uppgiftsminimering...
Läs merProtokollbeskrivning av OKI
Protokollbeskrivning av OKI Dokument: Protokollbeskrivning av OKI Sida 1 / 17 1 Syfte Det här dokumentet har som syfte att beskriva protokollet OKI. 2 Sammanfattning OKI är tänkt som en öppen standard
Läs merEfos PKI-struktur. Den nya PKI-strukturen. Användningsområden för certifikat
Efos PKI-struktur I samband med lanseringen av E-identitet för offentlig sektor (Efos) hos Försäkringskassan kommer certifikat börja ges ut från en annan PKI-struktur istället för SITHS Root CA v1 som
Läs merElektronisk remiss. Beskrivning och tjänstespecifika villkor
Elektronisk remiss Beskrivning och tjänstespecifika villkor Innehåll 1. INLEDNING... 2 2. BAKGRUND... 2 3. REFERENSER... 2 4. termer och begrepp... 2 5. BESKRIVNING AV TJÄNSTEN... 3 6. ANSLUTNING TILL
Läs mer